From daemon@optimus.ietf.org Fri Mar 1 02:17:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15448 for ; Fri, 1 Mar 2002 02:17:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06498 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 02:17:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28283; Fri, 1 Mar 2002 01:54:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28252 for ; Fri, 1 Mar 2002 01:54:15 -0500 (EST) Received: from cjstls3 ([61.38.87.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07253 for ; Fri, 1 Mar 2002 01:54:12 -0500 (EST) Message-Id: <200203010654.BAA07253@ietf.org> Reply-To: cjstls3@hotmail.com From: 운산 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 1 Mar 2002 15:56:15 +0900 Subject: [Sip] [광고]여러분의 잃어버린 행복의 복까지 찾아드립니다. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org
운산운세정보
본 메일은 정보통신부 권고사항에 의거,제목에 [광고]란이 표시된 메일입니다.
허락없이 광고메일을 보내드려 죄송하며,정중히 양해 바랍니다.
메일주소는 게시판,동호회등의 공개 메일주소를 수집하여, 다른 개인정보는 없음을 알려드립니다.

운산운세정보에서는 다른 실시간상담업체와 달리 많은 상담선생님을 초빙하지 않고, 회사의 엄격한 기준에 부합된 상담선생님들만 모셔서 24시간 1:1 상담이 될 수 있도록 하였습니다. (홈페이지로 이동,무료상담실 운영)

직업운, 시험운, 진학운, 애정운, 사랑운, 건강운, 사업운, 꿈해몽, 토정비결, 속궁합 겉궁합, 승진운, 작명, 택일, 사주팔자, 풍수지리...
     
   
 
1.
 지역번호 없이(휴대폰 포함) 060-700-8865번으로 전화를 겁니다(전국단일요금)
2.


 1번을 누르시면 대기중인 상담선생님과 자동연결되고, 2번을 누르시고 원하는 상담선생님 고유번호를 누르시면 선택한 역술상담선생님과 통화할 수 있습니다. 이용중 문의 사항이나 불편사항은 이메일로 연락주시기 바랍니다.
 
     
   
  상담하실 내용을 미리 마음속으로 정리를 하거나 메모를 해 보세요.
그리고 상담선생님과 연결이 되면 상담하실 내용을 차근차근 설명을 하시면 보다 편리하게 상담을 하실 수 있을 겁니다. 상담내용은 일체 비밀이므로, 편안한 마음과 자세로 상담 해보세요.		  
     
   
  서비스 이용요금은 사용 후, 익월에 사용한 내역이 정보이용료 사용하신 전화요금에 함께 청구되도록 되어 있어 결재시 불편함이 없습니다.  
   

           "역학은 통계에 의한 과학적인 학문입니다"
                   Copyright (c) 2002 운산운세정보 All rights reserved 		 
(사)한국전화정보통신협회 심의필번호 200112-223          불건전 정보신고 ☎080-700-3700
이 메일의 수신을 원하지 않으시면 수신거부 를 눌러 주세요.
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 1 06:53:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12209 for ; Fri, 1 Mar 2002 06:53:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA12745 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 06:53:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01568; Fri, 1 Mar 2002 06:28:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01334 for ; Fri, 1 Mar 2002 06:28:18 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10536 for ; Fri, 1 Mar 2002 06:28:14 -0500 (EST) Received: (qmail 28720 invoked from network); 1 Mar 2002 11:30:49 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 1 Mar 2002 11:30:49 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id 06E6022817; Fri, 1 Mar 2002 06:26:46 -0500 (EST) Message-ID: <3C7F6578.4010902@stake.com> Date: Fri, 01 Mar 2002 11:26:48 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gonzalo Camarillo Cc: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <3C7D29F1.4080401@stake.com> <1014837295.1201.20.camel@rjs.dynamicsoft.com> <3C7E65AB.2080006@stake.com> <3C7E6E30.B7766146@lmf.ericsson.se> <3C7EA816.8040702@stake.com> <3C7EAAE5.D7D72526@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ...Umm, So if the Target-URI is changed in the middle of the dialog by a re-Invite it makes sense that the underlying Media Stream will be changed as well? Why sending signaling to one place, and sending Media Streams to another place? Ofir Gonzalo Camarillo wrote: > Hi, > > That's right. The only thing that you can change in the target... well, > if you consider the local and remote cseqs as pieces of state as well, > they change in every request. > > Gonzalo > > Ofir Arkin wrote: > >>So, there is no way to change other state information other than the >>last hop (target URI)? >> >>Ofir >> >>Gonzalo Camarillo wrote: >> >> >>>It will change the last hop (the target) for the route of the dialog. >>> >>>Gonzalo >>> >>>Ofir Arkin wrote: >>> >>> >>>>What 'state' information does this change? >>>>For example if I send a Re-INVITE within a dialog what 'state' >>>>information will the Re-INVITE change? >>>> >>>> >>>> >>>>>>Second Question: >>>>>>Why this might change the target URI? >>>>>>I must admit that the target refresh thing got me really confused... >>>>>> >>>>>> >>>>>> >>>>>This mechanism allows an endpoint to change the URI it wants to be >>>>>handed in future requests within this dialog. This can be used as a >>>>>place to store state for future requests. The original proponents >>>>>planned to use this as part of the mechanics to deal with mobility >>>>>(address mobility in particular). I don't believe those ideas have >>>>>been fleshed out. >>>>> >>>>> >>>> >>>>-- >>>>Ofir Arkin >>>>Managing Security Architect >>>>@stake, Limited. >>>>http://www.atstake.com >>>>email: >>>>ofir@stake.com >>>>Tel: >>>>+44 (0) 207 495 7002 >>>>Fax: >>>>+44 (0) 207 495 7062 >>>>Mobile: +44 (0) 779 630 8632 >>>> >>>>----------------------------- >>>>The information transmitted is intended only for the person or entity to >>>>which it is addressed and may contain confidential and/or privileged >>>>material. Any review, re transmission, dissemination or other use of, >>>>or taking of any action in reliance upon, this information by persons or >>>>entities other than the intended recipient is prohibited. If you >>>>received this in error, please contact the sender and delete the >>>>material from any computer. >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>>> >>>> >>-- >>Ofir Arkin >>Managing Security Architect >>@stake, Limited. >>http://www.atstake.com >>email: >>ofir@stake.com >>Tel: >>+44 (0) 207 495 7002 >>Fax: >>+44 (0) 207 495 7062 >>Mobile: +44 (0) 779 630 8632 >> >>----------------------------- >>The information transmitted is intended only for the person or entity to >>which it is addressed and may contain confidential and/or privileged >>material. Any review, re transmission, dissemination or other use of, >>or taking of any action in reliance upon, this information by persons or >>entities other than the intended recipient is prohibited. If you >>received this in error, please contact the sender and delete the >>material from any computer. >> > -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 1 06:58:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12437 for ; Fri, 1 Mar 2002 06:58:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA14121 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 06:58:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05138; Fri, 1 Mar 2002 06:38:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05107 for ; Fri, 1 Mar 2002 06:38:49 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11187 for ; Fri, 1 Mar 2002 06:38:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21BdNi16355 for ; Fri, 1 Mar 2002 13:39:23 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 13:38:47 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 13:38:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question about Section 12.2 Requests within a Dialog Date: Fri, 1 Mar 2002 13:38:47 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777909F@esebe019.NOE.Nokia.com> Thread-Topic: [Sip] Question about Section 12.2 Requests within a Dialog Thread-Index: AcHBFHOuwhyVVXj7QduLNOKX83fM7AAAPE9g To: , Cc: , X-OriginalArrivalTime: 01 Mar 2002 11:38:47.0462 (UTC) FILETIME=[A67ABC60:01C1C115] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA05108 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext Ofir Arkin [mailto:ofir@stake.com] > Sent: Friday, March 01, 2002 1:27 PM > To: Gonzalo Camarillo > Cc: Robert Sparks; SIP > Subject: Re: [Sip] Question about Section 12.2 Requests > within a Dialog > > > ...Umm, > > So if the Target-URI is changed in the middle of the dialog by a > re-Invite it makes sense that the underlying Media Stream will be > changed as well? Possible, but not necessary. > > Why sending signaling to one place, and sending Media Streams > to another > place? 3PCC is one example. Regards, Hisham > > Ofir > > Gonzalo Camarillo wrote: > > > Hi, > > > > That's right. The only thing that you can change in the > target... well, > > if you consider the local and remote cseqs as pieces of > state as well, > > they change in every request. > > > > Gonzalo > > > > Ofir Arkin wrote: > > > >>So, there is no way to change other state information other than the > >>last hop (target URI)? > >> > >>Ofir > >> > >>Gonzalo Camarillo wrote: > >> > >> > >>>It will change the last hop (the target) for the route of > the dialog. > >>> > >>>Gonzalo > >>> > >>>Ofir Arkin wrote: > >>> > >>> > >>>>What 'state' information does this change? > >>>>For example if I send a Re-INVITE within a dialog what 'state' > >>>>information will the Re-INVITE change? > >>>> > >>>> > >>>> > >>>>>>Second Question: > >>>>>>Why this might change the target URI? > >>>>>>I must admit that the target refresh thing got me > really confused... > >>>>>> > >>>>>> > >>>>>> > >>>>>This mechanism allows an endpoint to change the URI it > wants to be > >>>>>handed in future requests within this dialog. This can > be used as a > >>>>>place to store state for future requests. The original proponents > >>>>>planned to use this as part of the mechanics to deal > with mobility > >>>>>(address mobility in particular). I don't believe those > ideas have > >>>>>been fleshed out. > >>>>> > >>>>> > >>>> > >>>>-- > >>>>Ofir Arkin > >>>>Managing Security Architect > >>>>@stake, Limited. > >>>>http://www.atstake.com > >>>>email: > >>>>ofir@stake.com > >>>>Tel: > >>>>+44 (0) 207 495 7002 > >>>>Fax: > >>>>+44 (0) 207 495 7062 > >>>>Mobile: +44 (0) 779 630 8632 > >>>> > >>>>----------------------------- > >>>>The information transmitted is intended only for the > person or entity to > >>>>which it is addressed and may contain confidential and/or > privileged > >>>>material. Any review, re transmission, dissemination or > other use of, > >>>>or taking of any action in reliance upon, this > information by persons or > >>>>entities other than the intended recipient is prohibited. If you > >>>>received this in error, please contact the sender and delete the > >>>>material from any computer. > >>>> > >>>>_______________________________________________ > >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>This list is for NEW development of the core SIP Protocol > >>>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>>Use sipping@ietf.org for new developments on the > application of sip > >>>> > >>>> > >>-- > >>Ofir Arkin > >>Managing Security Architect > >>@stake, Limited. > >>http://www.atstake.com > >>email: > >>ofir@stake.com > >>Tel: > >>+44 (0) 207 495 7002 > >>Fax: > >>+44 (0) 207 495 7062 > >>Mobile: +44 (0) 779 630 8632 > >> > >>----------------------------- > >>The information transmitted is intended only for the person > or entity to > >>which it is addressed and may contain confidential and/or privileged > >>material. Any review, re transmission, dissemination or > other use of, > >>or taking of any action in reliance upon, this information > by persons or > >>entities other than the intended recipient is prohibited. If you > >>received this in error, please contact the sender and delete the > >>material from any computer. > >> > > > > > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person > or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, dissemination or > other use of, > or taking of any action in reliance upon, this information by > persons or > entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 1 07:28:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17364 for ; Fri, 1 Mar 2002 07:28:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23690 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 07:28:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21999; Fri, 1 Mar 2002 07:07:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21965 for ; Fri, 1 Mar 2002 07:07:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14966; Fri, 1 Mar 2002 07:07:18 -0500 (EST) Message-Id: <200203011207.HAA14966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:07:18 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-100rel-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Reliability of Provisional Responses in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-100rel-06.txt Pages : 14 Date : 28-Feb-02 This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag org.ietf.sip.100rel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-100rel-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-100rel-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228140001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-100rel-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-100rel-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228140001.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 daemon@optimus.ietf.org Fri Mar 1 07:28:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17382 for ; Fri, 1 Mar 2002 07:28:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23704 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 07:28:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22089; Fri, 1 Mar 2002 07:07:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22020 for ; Fri, 1 Mar 2002 07:07:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15038; Fri, 1 Mar 2002 07:07:27 -0500 (EST) Message-Id: <200203011207.HAA15038@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:07:27 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-srv-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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: Locating SIP Servers Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-srv-06.txt Pages : 18 Date : 28-Feb-02 The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-srv-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-srv-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228140025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-srv-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-srv-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228140025.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 daemon@optimus.ietf.org Fri Mar 1 07:28:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17395 for ; Fri, 1 Mar 2002 07:28:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23718 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 07:28:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22150; Fri, 1 Mar 2002 07:07:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22063 for ; Fri, 1 Mar 2002 07:07:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15063; Fri, 1 Mar 2002 07:07:32 -0500 (EST) Message-Id: <200203011207.HAA15063@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:07:31 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-09.txt,.ps,.pdf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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: Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne et al. Filename : draft-ietf-sip-rfc2543bis-09.txt,.ps,.pdf Pages : 276 Date : 28-Feb-02 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc2543bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228140040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228140040.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 daemon@optimus.ietf.org Fri Mar 1 07:29:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17465 for ; Fri, 1 Mar 2002 07:29:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23747 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 07:29:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22049; Fri, 1 Mar 2002 07:07:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA22003 for ; Fri, 1 Mar 2002 07:07:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15008; Fri, 1 Mar 2002 07:07:23 -0500 (EST) Message-Id: <200203011207.HAA15008@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:07:22 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-events-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sip-events-04.txt Pages : 37 Date : 28-Feb-02 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-events-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-events-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-events-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228140013.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-events-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-events-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228140013.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 daemon@optimus.ietf.org Fri Mar 1 07:33:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17584 for ; Fri, 1 Mar 2002 07:33:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA24180 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 07:33:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21954; Fri, 1 Mar 2002 07:07:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21925 for ; Fri, 1 Mar 2002 07:07:15 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14948; Fri, 1 Mar 2002 07:07:11 -0500 (EST) Message-Id: <200203011207.HAA14948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:07:11 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-manyfolks-resource-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Integration of Resource Management and SIP Author(s) : W. Marshall et al. Filename : draft-ietf-sip-manyfolks-resource-04.txt Pages : 23 Date : 28-Feb-02 This document discusses how network quality of service can be made a precondition to establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-manyfolks-resource-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228135948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-manyfolks-resource-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228135948.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 daemon@optimus.ietf.org Fri Mar 1 09:02:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25080 for ; Fri, 1 Mar 2002 09:02:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28118 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 09:02:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26372; Fri, 1 Mar 2002 08:34:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26348 for ; Fri, 1 Mar 2002 08:33:56 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23632 for ; Fri, 1 Mar 2002 08:33:54 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id IAA09716; Fri, 1 Mar 2002 08:33:25 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B6F.004A70E8 ; Fri, 1 Mar 2002 08:33:05 -0500 X-Lotus-FromDomain: MITEL To: "Bob Penfield" cc: "Mark Taylor" , "SIP" Message-ID: <85256B6F.004A6F9A.00@kanmta01.software.mitel.com> Date: Fri, 1 Mar 2002 08:33:11 -0500 Subject: Home Extension Service was Re: [Sip] Multiple 200 OKs for an INVITE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 03/01/2002 08:33 AM The scenario pointed out with multiple 200 OKs is also pertinent for a home extension service. Have the call flows for this service been created, I find in the service example draft a mention that they have not. It also raises questions about who will supply and pay for a conference service to a home extension. Callers would be hesitant to pay for a conference connection that was of benefit only to the called party. "Bob Penfield" on 02/28/2002 12:09:32 PM To: "Mark Taylor" , "SIP" cc: (bcc: Tom Gray/Kan/Mitel) Subject: Re: [Sip] Multiple 200 OKs for an INVITE ----- Original Message ----- From: "Mark Taylor" > > This may be a silly question but multiple INVITES are > sent out which cause telephones to ring. Two of these > telephones are answered by human beings at the same > time and send a 200 OK. One of these telephones is > connected to the voice path but the other experiences > an immediate hang up. > > Isn't this extremely rude and will cause major > emabarassment to the caller since his name and > possibly picture have been dispayed on the receiving > device. It could also be considered a form of criminal > harrassment to call and imediately hang up on answer. I think it is a rather common occurance that you pick up a phone and say hello and noone is there because they decided the call was a mistake or got tired of waiting for it to answer. It happens to me quite often, particularly if I don't pick up for 3 or 4 rings. I should also point out that proxies are required to CANCEL the other branches when one of them answers. Therefore, the other unanswered phones would likely stop ringing with a second or two. You might consider it rude, but the reason that more than one phone rang is because a user wanted all those phones to ring when he/she got called. The theory being that the user would answer the phone he/she is next to and there would be noone next to the other devices. However, some polite person might decide they want to answer the user's unattended phone for them. > > It should be noted that for calls to human beings as > oposed to machines that all end points that send a > 200K must be conferenced into the connection. This is not always possible, particularly on a small device with limited resources. cheers, (-:bob _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 1 09:11:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25597 for ; Fri, 1 Mar 2002 09:11:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28375 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 09:11:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27132; Fri, 1 Mar 2002 08:49:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27104 for ; Fri, 1 Mar 2002 08:49:52 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24442 for ; Fri, 1 Mar 2002 08:49:49 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GSA00601RQ9WJ@firewall.wcom.com> for sip@ietf.org; Fri, 1 Mar 2002 13:49:21 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GSA005EVRQ9VT@firewall.wcom.com>; Fri, 01 Mar 2002 13:49:21 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GSA00301RPY7D@dgismtp01.wcomnet.com>; Fri, 01 Mar 2002 13:49:21 +0000 (GMT) Received: from ajohnston ([166.44.58.247]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GSA001FHRPUA7@dgismtp01.wcomnet.com>; Fri, 01 Mar 2002 13:49:08 +0000 (GMT) Date: Fri, 01 Mar 2002 07:48:39 -0600 From: Alan Johnston Subject: RE: Home Extension Service was Re: [Sip] Multiple 200 OKs for an INVITE In-reply-to: <85256B6F.004A6F9A.00@kanmta01.software.mitel.com> To: Tom_Gray@Mitel.COM, "'Bob Penfield'" Cc: "'Mark Taylor'" , "'SIP'" Message-id: <004d01c1c127$cbc27a50$64202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tom, You are correct - the home extension (sometimes called single line extension) is not yet in the Service Examples I-D. This is because not all the tools needed to do so are SIP WG items - something that will hopefully change shortly. In the meantime, take a look at Section 7.2 of: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-call-package- 00.txt For one possible approach. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Tom_Gray@Mitel.COM > Sent: Friday, March 01, 2002 7:33 AM > To: Bob Penfield > Cc: Mark Taylor; SIP > Subject: Home Extension Service was Re: [Sip] Multiple 200 > OKs for an INVITE > > > > > From: Tom Gray@MITEL on 03/01/2002 08:33 AM > > The scenario pointed out with multiple 200 OKs is also > pertinent for a home extension service. Have the call flows > for this service been created, I find in the service example > draft a mention that they have not. It also raises questions > about who will supply and pay for a conference service to a > home extension. Callers would be hesitant to pay for a > conference connection that was of benefit only to the called party. > > > > > > "Bob Penfield" on 02/28/2002 12:09:32 PM > > To: "Mark Taylor" , "SIP" > cc: (bcc: Tom Gray/Kan/Mitel) > > Subject: Re: [Sip] Multiple 200 OKs for an INVITE > > > > > ----- Original Message ----- > From: "Mark Taylor" > > > > > This may be a silly question but multiple INVITES are > > sent out which cause telephones to ring. Two of these > telephones are > > answered by human beings at the same time and send a 200 OK. One of > > these telephones is connected to the voice path but the other > > experiences an immediate hang up. > > > > Isn't this extremely rude and will cause major > > emabarassment to the caller since his name and > > possibly picture have been dispayed on the receiving > > device. It could also be considered a form of criminal > harrassment to > > call and imediately hang up on answer. > > I think it is a rather common occurance that you pick up a > phone and say hello and noone is there because they decided > the call was a mistake or got tired of waiting for it to > answer. It happens to me quite often, particularly if I don't > pick up for 3 or 4 rings. > > I should also point out that proxies are required to CANCEL > the other branches when one of them answers. Therefore, the > other unanswered phones would likely stop ringing with a > second or two. > > You might consider it rude, but the reason that more than one > phone rang is because a user wanted all those phones to ring > when he/she got called. The theory being that the user would > answer the phone he/she is next to and there would be noone > next to the other devices. However, some polite person might > decide they want to answer the user's unattended phone for them. > > > > > It should be noted that for calls to human beings as > > oposed to machines that all end points that send a > > 200K must be conferenced into the connection. > > This is not always possible, particularly on a small device > with limited resources. > > cheers, > (-:bob > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 10:12:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29147 for ; Fri, 1 Mar 2002 10:12:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01858 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 10:12:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29792; Fri, 1 Mar 2002 09:37:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29762 for ; Fri, 1 Mar 2002 09:37:55 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27308 for ; Fri, 1 Mar 2002 09:37:53 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id JAA04278; Fri, 1 Mar 2002 09:37:15 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B6F.00504B0A ; Fri, 1 Mar 2002 09:37:00 -0500 X-Lotus-FromDomain: MITEL To: Alan Johnston , Tom_Gray@Mitel.COM cc: "'Bob Penfield'" , "'Mark Taylor'" , "'SIP'" Message-ID: <85256B6F.005043BA.00@kanmta01.software.mitel.com> Date: Fri, 1 Mar 2002 09:08:37 -0500 Subject: RE: Home Extension Service was Re: [Sip] Multiple 200 OKs for an INVITE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 03/01/2002 09:08 AM Thanks for the pointer. Looking at the call package draft show the handling of the home extension case. The specific contingency of multiple 200 OKs does not seem to have been considered in that case but the techniques described there do seem capable of handling that situation. I suppose that that contingency isn't directly germane to the call package draft but it is particularly important in any future description of this service. I think that this shows that the situation of baseline SIP phones and multiple 200 OKs is not as straightforward as it seems. it looks as if even very cheap SIP phones are going to have to be able handle subscribes and local or network conference services for a significant number of parties. This puts a different light on the matter of just sending ACK/BYE in the case of multiple 200 OKs. Alan Johnston on 03/01/2002 08:48:39 AM To: Tom Gray/Kan/Mitel@Mitel, "'Bob Penfield'" cc: "'Mark Taylor'" , "'SIP'" Subject: RE: Home Extension Service was Re: [Sip] Multiple 200 OKs for an INVITE Tom, You are correct - the home extension (sometimes called single line extension) is not yet in the Service Examples I-D. This is because not all the tools needed to do so are SIP WG items - something that will hopefully change shortly. In the meantime, take a look at Section 7.2 of: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-call-package- 00.txt For one possible approach. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Tom_Gray@Mitel.COM > Sent: Friday, March 01, 2002 7:33 AM > To: Bob Penfield > Cc: Mark Taylor; SIP > Subject: Home Extension Service was Re: [Sip] Multiple 200 > OKs for an INVITE > > > > > From: Tom Gray@MITEL on 03/01/2002 08:33 AM > > The scenario pointed out with multiple 200 OKs is also > pertinent for a home extension service. Have the call flows > for this service been created, I find in the service example > draft a mention that they have not. It also raises questions > about who will supply and pay for a conference service to a > home extension. Callers would be hesitant to pay for a > conference connection that was of benefit only to the called party. > > > > > > "Bob Penfield" on 02/28/2002 12:09:32 PM > > To: "Mark Taylor" , "SIP" > cc: (bcc: Tom Gray/Kan/Mitel) > > Subject: Re: [Sip] Multiple 200 OKs for an INVITE > > > > > ----- Original Message ----- > From: "Mark Taylor" > > > > > This may be a silly question but multiple INVITES are > > sent out which cause telephones to ring. Two of these > telephones are > > answered by human beings at the same time and send a 200 OK. One of > > these telephones is connected to the voice path but the other > > experiences an immediate hang up. > > > > Isn't this extremely rude and will cause major > > emabarassment to the caller since his name and > > possibly picture have been dispayed on the receiving > > device. It could also be considered a form of criminal > harrassment to > > call and imediately hang up on answer. > > I think it is a rather common occurance that you pick up a > phone and say hello and noone is there because they decided > the call was a mistake or got tired of waiting for it to > answer. It happens to me quite often, particularly if I don't > pick up for 3 or 4 rings. > > I should also point out that proxies are required to CANCEL > the other branches when one of them answers. Therefore, the > other unanswered phones would likely stop ringing with a > second or two. > > You might consider it rude, but the reason that more than one > phone rang is because a user wanted all those phones to ring > when he/she got called. The theory being that the user would > answer the phone he/she is next to and there would be noone > next to the other devices. However, some polite person might > decide they want to answer the user's unattended phone for them. > > > > > It should be noted that for calls to human beings as > > oposed to machines that all end points that send a > > 200K must be conferenced into the connection. > > This is not always possible, particularly on a small device > with limited resources. > > cheers, > (-:bob > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 11:29:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03978 for ; Fri, 1 Mar 2002 11:29:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09008 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 11:29:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03988; Fri, 1 Mar 2002 10:43:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03955 for ; Fri, 1 Mar 2002 10:43:43 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00902 for ; Fri, 1 Mar 2002 10:43:40 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA25442; Fri, 1 Mar 2002 16:43:39 +0100 (MET) Received: from mchh159e.mch4.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA04319; Fri, 1 Mar 2002 16:43:30 +0100 (MET) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 16:43:37 +0100 Message-ID: <5B4D0C5BA65ECA46969C1419122317E60817A6@mchh161e> From: Tan Ya-Ching ICM N PG U ID A 1 To: "'Jonathan Rosenberg'" Cc: Robert Sparks , SIP Subject: RE: [Sip] Question about Section 12.2 Requests within a Dialog Date: Fri, 1 Mar 2002 16:43:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org | -----Original Message----- | From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] | | | Ofir Arkin wrote: | > | > What 'state' information does this change? | > For example if I send a Re-INVITE within a dialog what 'state' | > information will the Re-INVITE change? | | The re-INVITE changes the remote URI. | | Here is an example. I send an INVITE with a Cotnact header of | sip:@. The call is established. A BYE, | re-INVITE, or other mid-dialog request will arrive to me with this URI | in the request URI. I can use that for whatever purposes I like. If I | wish to change it, I can issue a re-INVITE, which updates it at the | other side. | I have a question about the sentence "I can use that (URI learned from Contact header) for whatever purposes I like". What is the scope of such a URI ? I always assumed that one can use that only for requests sent within that dialog. But Section 8.2.2.1 line 1279 of bis-09 states that "Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs". Bearing in mind that in Section 8 we are talking about "(line 962) method-independant rules for UAC and UAS behavior when processing requests that are OUTSIDE of a dialog", which means initial INVITE or OPTIONS, surely the URI from Contact cannot be used in the URI for these requests. This sentence should be relocated to Section 12. - Ya-Ching Tan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 12:01:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06334 for ; Fri, 1 Mar 2002 12:01:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12974 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 12:01:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09342; Fri, 1 Mar 2002 11:30:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09313 for ; Fri, 1 Mar 2002 11:30:47 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04068 for ; Fri, 1 Mar 2002 11:30:44 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g21GUhh20431; Fri, 1 Mar 2002 10:30:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g21GUhI26963; Fri, 1 Mar 2002 10:30:43 -0600 (CST) Received: from lmf.ericsson.se (rmt160239.am.ericsson.se [138.85.160.239]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA12228; Fri, 1 Mar 2002 10:30:40 -0600 (CST) Message-ID: <3C7FACE5.99F17F85@lmf.ericsson.se> Date: Fri, 01 Mar 2002 18:31:33 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: "'Jonathan Rosenberg'" , Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <5B4D0C5BA65ECA46969C1419122317E60817A6@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The URI in the contact needs to have global scope so that, among other services, call transfer can be implemented. Gonzalo Tan Ya-Ching ICM N PG U ID A 1 wrote: > > | -----Original Message----- > | From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > | > | > | Ofir Arkin wrote: > | > > | > What 'state' information does this change? > | > For example if I send a Re-INVITE within a dialog what 'state' > | > information will the Re-INVITE change? > | > | The re-INVITE changes the remote URI. > | > | Here is an example. I send an INVITE with a Cotnact header of > | sip:@. The call is established. A BYE, > | re-INVITE, or other mid-dialog request will arrive to me with this URI > | in the request URI. I can use that for whatever purposes I like. If I > | wish to change it, I can issue a re-INVITE, which updates it at the > | other side. > | > > I have a question about the sentence "I can use that (URI learned from > Contact header) for whatever purposes I like". What is the scope of such a > URI ? I always assumed that one can use that only for requests sent within > that dialog. But Section 8.2.2.1 line 1279 of bis-09 states that "Other > potential sources of received Request-URIs include the Contact header fields > of requests and responses sent by the UA that establish or refresh dialogs". > Bearing in mind that in Section 8 we are talking about "(line 962) > method-independant rules for UAC and UAS behavior when processing requests > that are OUTSIDE of a dialog", which means initial INVITE or OPTIONS, surely > the URI from Contact cannot be used in the URI for these requests. This > sentence should be relocated to Section 12. > > - Ya-Ching Tan > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Fri Mar 1 12:17:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07459 for ; Fri, 1 Mar 2002 12:17:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14021 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 12:17:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11244; Fri, 1 Mar 2002 11:53:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11207 for ; Fri, 1 Mar 2002 11:53:40 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05660 for ; Fri, 1 Mar 2002 11:53:37 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GSB0080108KIF@firewall.wcom.com> for sip@ietf.org; Fri, 1 Mar 2002 16:53:08 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GSB007CD08KID@firewall.wcom.com>; Fri, 01 Mar 2002 16:53:08 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSB0080108KG5@dgismtp06.wcomnet.com>; Fri, 01 Mar 2002 16:53:08 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSB005NN08I9E@dgismtp06.wcomnet.com>; Fri, 01 Mar 2002 16:53:08 +0000 (GMT) Date: Fri, 01 Mar 2002 10:53:05 -0600 From: Henry Sinnreich Subject: RE: Home Extension Service was Re: [Sip] Multiple 200 OKs for an INVITE In-reply-to: <85256B6F.005043BA.00@kanmta01.software.mitel.com> To: Tom_Gray@Mitel.COM Cc: "'Bob Penfield'" , "'Alan Johnston'" , "'Mark Taylor'" , "'SIP'" Message-id: <000201c1c141$8fc482e0$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tom, > it looks as if even very cheap > SIP phones are going to have to be able handle subscribes and > local or network conference services for a significant number > of parties. Please see also the three new drafts have been submitted on SIP devices and can be retrieved here until they will be available from the IETF archive. Let us know what may have been missed. http://www.pingtel.com/docs/draft-sinnreich-sipping-device-requirements- 00.txt SIP Telephony Device Requirements Abstract The SIP Telephony Device Requirements in this document are aimed to enable users to procure SIP phones from various vendors and install them using a configuration process over the network, though still allowing manual configuration data input if desired. SIP telephony devices are also required to be updated up automatically, without the intervention of the end user. The requirements are aimed to allow service providers to support large numbers of SIP telephony devices from different vendors and SHOULD be used as a checklist for developers of SIP phones. SIP telephony devices may support basic telephony as well as advanced services such as PBX and Centrex-like telephony, third party call control, presence based services, roaming and other applications. The requirements aim to insure multi-vendor interoperability over the Internet and in private IP networks for such services. http://www.pingtel.com/docs/draft-stredicke-sipping-ep-config-00.txt SIP End Point Configuration Data Format Abstract Mass deployment of SIP compliant devices requires a simple mechanism for configuring and maintaining them. For the economical success of SIP based devices on a large scale, a platform independent mechanism for finding and exchanging the required information is vital. The goal of this draft is to reduce the amount of effort required for administrators to provision devices. This draft focuses on defining a common data set to configure SIP end points. The mechanism for providing and maintaining the configuration data to the end point is defined elsewhere [7]. This Internet draft is a sub-package to SIP-Specific Event Notification [2]. A Framework for SIP User Agent Configuration http://www.ietf.org/internet-drafts/draft-petrie-sip-config-framework-01 .txt Abstract This document defines the application of a set of protocols for configuring a SIP user agent. The SIP user agent must discover how and from where to retrieve its initial configuration and be notified of changes and updates which impact its configuration. The objective is to define a means for automatically configuring a user agent such that it can be functional without user or administrative intervention. The framework for discovery, delivery, notification and updates of user agent configuration is defined here. This framework is also intended to ease ongoing administration, configuration and upgrading of large scale deployments of SIP user agents. The contents and format of the configuration data to be defined is outside the scope of this document. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Tom_Gray@Mitel.COM > Sent: Friday, March 01, 2002 8:09 AM > To: Alan Johnston; Tom_Gray@Mitel.COM > Cc: 'Bob Penfield'; 'Mark Taylor'; 'SIP' > Subject: RE: Home Extension Service was Re: [Sip] Multiple > 200 OKs for an INVITE > > > > > From: Tom Gray@MITEL on 03/01/2002 09:08 AM > > Thanks for the pointer. Looking at the call package draft > show the handling of the home extension case. The specific > contingency of multiple 200 OKs does not seem to have been > considered in that case but the techniques described there do > seem capable of handling that situation. I suppose that that > contingency isn't directly germane to the call package draft > but it is particularly important in any future description of > this service. I think that this shows that the situation of > baseline SIP phones and multiple 200 OKs is not as > straightforward as it seems. it looks as if even very cheap > SIP phones are going to have to be able handle subscribes and > local or network conference services for a significant number > of parties. This puts a different light on the matter of just > sending ACK/BYE in the case of multiple 200 OKs. > > > > > > > Alan Johnston on 03/01/2002 08:48:39 AM > > To: Tom Gray/Kan/Mitel@Mitel, "'Bob Penfield'" > > cc: "'Mark Taylor'" , "'SIP'" > > Subject: RE: Home Extension Service was Re: [Sip] Multiple > 200 OKs for an > INVITE > > > > Tom, > > You are correct - the home extension (sometimes called single line > extension) is not yet in the Service Examples I-D. This is > because not all the tools needed to do so are SIP WG items - > something that will hopefully change shortly. > > In the meantime, take a look at Section 7.2 of: > > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-cal > l-package- > 00.txt > > For one possible approach. > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.com > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > > Tom_Gray@Mitel.COM > > Sent: Friday, March 01, 2002 7:33 AM > > To: Bob Penfield > > Cc: Mark Taylor; SIP > > Subject: Home Extension Service was Re: [Sip] Multiple 200 > OKs for an > > INVITE > > > > > > > > > > From: Tom Gray@MITEL on 03/01/2002 08:33 AM > > > > The scenario pointed out with multiple 200 OKs is also > pertinent for a > > home extension service. Have the call flows for this service been > > created, I find in the service example draft a mention that > they have > > not. It also raises questions about who will supply and pay for a > > conference service to a home extension. Callers would be > hesitant to > > pay for a conference connection that was of benefit only to > the called > > party. > > > > > > > > > > > > "Bob Penfield" on 02/28/2002 12:09:32 PM > > > > To: "Mark Taylor" , "SIP" > > cc: (bcc: Tom Gray/Kan/Mitel) > > > > Subject: Re: [Sip] Multiple 200 OKs for an INVITE > > > > > > > > > > ----- Original Message ----- > > From: "Mark Taylor" > > > > > > > > This may be a silly question but multiple INVITES are > > > sent out which cause telephones to ring. Two of these > > telephones are > > > answered by human beings at the same time and send a 200 > OK. One of > > > these telephones is connected to the voice path but the other > > > experiences an immediate hang up. > > > > > > Isn't this extremely rude and will cause major > emabarassment to the > > > caller since his name and possibly picture have been > dispayed on the > > > receiving device. It could also be considered a form of criminal > > harrassment to > > > call and imediately hang up on answer. > > > > I think it is a rather common occurance that you pick up a > phone and > > say hello and noone is there because they decided the call was a > > mistake or got tired of waiting for it to answer. It happens to me > > quite often, particularly if I don't pick up for 3 or 4 rings. > > > > I should also point out that proxies are required to CANCEL > the other > > branches when one of them answers. Therefore, the other unanswered > > phones would likely stop ringing with a second or two. > > > > You might consider it rude, but the reason that more than one phone > > rang is because a user wanted all those phones to ring when > he/she got > > called. The theory being that the user would answer the > phone he/she > > is next to and there would be noone next to the other devices. > > However, some polite person might decide they want to answer the > > user's unattended phone for them. > > > > > > > > It should be noted that for calls to human beings as > > > oposed to machines that all end points that send a > > > 200K must be conferenced into the connection. > > > > This is not always possible, particularly on a small device with > > limited resources. > > > > cheers, > > (-:bob > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 12:34:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08989 for ; Fri, 1 Mar 2002 12:34:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15302 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 12:34:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13847; Fri, 1 Mar 2002 12:13:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13817 for ; Fri, 1 Mar 2002 12:13:01 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07129 for ; Fri, 1 Mar 2002 12:12:58 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g21HCTS27953; Fri, 1 Mar 2002 11:12:29 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g21HCTI18424; Fri, 1 Mar 2002 11:12:29 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g21HCSE14291; Fri, 1 Mar 2002 12:12:28 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 12:12:28 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037494@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Drage, Keith (Keith)'" , "'sip@ietf.org'" Subject: RE: [Sip] Path header: Independent operation in each direction, o r common o peration for both directions Date: Fri, 1 Mar 2002 12:12:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Examples or no examples, the PATH extenstion should be generic enough to handle independent PATH in each direction. 3GPP may impose its own limitations in 24229 & 24228. Everybody is happy. Rgds/gf Ericsson Canada > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, February 25, 2002 5:44 AM > To: 'sip@ietf.org' > Subject: [Sip] Path header: Independent operation in each > direction, or > common o peration for both directions > > > I am breaking out the issues that I think need more > discussion relating to > the proposed Path header. This is the first of those mails. > > Currently the mechanism specified for 3GPP looks very like > Record-Route and > it therefore collects the URLs of the proxies that wish to be > on the path > for future transactions by use of the header within the > REGISTER request, > and the response is merely a transport mechanism of the > gathered information > back to the UA from the registrar. > > This means that proxies so identified are intended to be in > the path for > both incoming and outgoing requests, as there is no means of > distinguishing > the two independently (or at least not with a single header, > or separate > lists within the common header). > > The mechanism proposed in Deans draft allows independent gathering of > information in each direction; a proxy that wishes to be on > the path in both > incoming and outgoing directions must insert its URL in both > the request and > the response. This loses the commonality of the procedures with > Record-Route. > > While both mechanisms work, having discussed the requirements > with a limited > set of people, we cannot think of a situation whereby a proxy > would want to > be on the incoming path and not on the outgoing path, and vice-versa. > Certainly in 3GPP, the requirement needs to apply in both directions. > Therefore the real question is are we developing a solution > that does more > that the requirements need, and therefore losing the commonality with > Record-Route as a result. > > [While there may be advantages of code sharing with Record-Route for > implementations, I am thinking more of the advantages to > understanding the > specification. People are more likely to understand and implement Path > correctly if it works the same way as something else.] > > So, those who need operations independently in both > directions, can you > shout up and give us some examples. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 17:13:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03122 for ; Fri, 1 Mar 2002 17:13:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03467 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 17:13:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01838; Fri, 1 Mar 2002 16:53:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01807 for ; Fri, 1 Mar 2002 16:53:29 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01599 for ; Fri, 1 Mar 2002 16:53:28 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g21LrUh18386 for ; Fri, 1 Mar 2002 15:53:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g21LrTe15055 for ; Fri, 1 Mar 2002 15:53:29 -0600 (CST) Received: from lmf.ericsson.se (rmt160168.am.ericsson.se [138.85.160.168]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA10797 for ; Fri, 1 Mar 2002 15:53:28 -0600 (CST) Message-ID: <3C7FF886.8BF6D7D7@lmf.ericsson.se> Date: Fri, 01 Mar 2002 23:54:14 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I have just submitted manyfolks 05. Until it appears in the archives, you can fetch it from: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-05.pdf http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-05.txt I have added a new example that shows how preconditions can be requested in an offer in a 1xx response. I have added some explanatory text here and there based on the comments I have received so far. Comments are welcome, as usual. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Fri Mar 1 17:28:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03851 for ; Fri, 1 Mar 2002 17:28:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03972 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 17:28:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03118; Fri, 1 Mar 2002 17:06:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03095 for ; Fri, 1 Mar 2002 17:06:33 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02788 for ; Fri, 1 Mar 2002 17:06:31 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g21M62d15803; Fri, 1 Mar 2002 14:06:02 -0800 (PST) Received: from dhcp-128-107-139-42.cisco.com (dhcp-128-107-139-42.cisco.com [128.107.139.42]) by imop.cisco.com (Mirapoint) with ESMTP id ACN86510; Fri, 1 Mar 2002 14:06:01 -0800 (PST) Date: Fri, 1 Mar 2002 14:04:20 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org cc: fandreas@cisco.com Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Everyone, Flemming just submitted the latest versions of call-auth and privacy. Until these appear in the archives, they can be found on the supplemental web site at: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-call-auth-04.txt http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-04.txt Thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 18:32:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06229 for ; Fri, 1 Mar 2002 18:32:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07752 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 18:32:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06321; Fri, 1 Mar 2002 18:09:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06290 for ; Fri, 1 Mar 2002 18:08:59 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05281 for ; Fri, 1 Mar 2002 18:08:57 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA04790 for ; Fri, 1 Mar 2002 18:08:17 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA22040 for ; Fri, 1 Mar 2002 18:07:51 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Mar 2002 18:07:50 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CB97@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Fri, 1 Mar 2002 18:07:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Path to Working Group Item Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There has been considerable discussion on the PATH header on the list indicating more than significant interest to consider it a working group item. Are there any objections? Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 20:10:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08882 for ; Fri, 1 Mar 2002 20:10:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA12523 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 20:10:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11499; Fri, 1 Mar 2002 19:45:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11468 for ; Fri, 1 Mar 2002 19:45:39 -0500 (EST) Received: from smtp3.ev1.net (smtpout.ev1.net [207.218.192.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08282 for ; Fri, 1 Mar 2002 19:45:36 -0500 (EST) Received: from u6x5c8 [216.40.219.49] by smtp3.ev1.net (SMTPD32-6.06) id A0C54FDB002A; Fri, 01 Mar 2002 18:45:57 -0600 Message-ID: <002c01c1c194$60151700$31db28d8@u6x5c8> From: "Mart Nurmet" To: "Rosen, Brian" , References: <313680C9A886D511A06000204840E1CF57CB97@whq-msgusr-02.pit.comms.marconi.com> Subject: Re: [Sip] Path to Working Group Item Date: Fri, 1 Mar 2002 18:45:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit No, go for it. - Mart ----- Original Message ----- From: "Rosen, Brian" To: Sent: Friday, March 01, 2002 3:07 PM Subject: [Sip] Path to Working Group Item > There has been considerable discussion on the PATH header on the list > indicating more than significant interest to consider it a working > group item. Are there any objections? > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 1 20:48:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09653 for ; Fri, 1 Mar 2002 20:48:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA13656 for sip-archive@odin.ietf.org; Fri, 1 Mar 2002 20:47:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13236; Fri, 1 Mar 2002 20:30:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13194 for ; Fri, 1 Mar 2002 20:30:28 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09258 for ; Fri, 1 Mar 2002 20:30:24 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA26692; Fri, 1 Mar 2002 20:28:17 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g221SGNB013486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 1 Mar 2002 20:28:16 -0500 (EST) Message-ID: <3C802AA4.9F59EE22@cs.columbia.edu> Date: Fri, 01 Mar 2002 20:28:04 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] Comments on Resource Priority Header References: <72.180e7809.29a69d65@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > An implementation would already need to have a procedure to follow if it got > a priority it did not understand, like defaulting to the lowest it knows. So Indeed. > if a new value were defined and an old implemenation received that new value, > that is what it would do. It just seems too restrictive to say that a > "domain" or network could never in the future add a new priority value. > Granted, the proper use of that new value would require upgrading any > equipment that might use the value in its processing, but then I suspect the > same will be true for many other improvements/extensions to the protocol in > the future. Isn't it true that the current situation is that a device must > ignore any thing it doesn't understand, just like http? Somebody (you?) argued that ignoring the value should not be the same as having the lowest priority value. > > I guess the use of "SHOULD NOT" in the draft in fact indicates that it could > be done, but it is not recommended, so I suppose this wording is acceptable. I added wording that the UA MUST ignore Resource-Priority headers with unknown values or name spaces. That seems to be common protocol behavior in other cases. The only real difference is that one could imagine that there are scenarios where certain Resource-Priority values are actually *below* normal treatment, kind of like the scavenger QoS mechanism. I don't know if any of the existing schemes have this behavior. Frankly, I don't see this as a problem in practice. Almost all of these namespaces will be inherited from some existing scheme, so the likelihood that somebody suddenly adds a value is pretty low. > > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 2 02:56:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25788 for ; Sat, 2 Mar 2002 02:56:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06270 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 02:56:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05931; Sat, 2 Mar 2002 02:30:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05891 for ; Sat, 2 Mar 2002 02:30:53 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25608 for ; Sat, 2 Mar 2002 02:30:51 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16h3y3-0005zd-00; Sat, 02 Mar 2002 09:30:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15488.32639.347801.830011@harjus.eng.song.fi> Date: Sat, 2 Mar 2002 09:30:07 +0200 To: "Rosen, Brian" Cc: "'sip@ietf.org'" Subject: [Sip] Path to Working Group Item In-Reply-To: <313680C9A886D511A06000204840E1CF57CB97@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF57CB97@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rosen, Brian writes: > There has been considerable discussion on the PATH header on the list > indicating more than significant interest to consider it a working > group item. Are there any objections? the number of people (in this case the mobile gang) interested in something should not be the only criteria of making that something a sip working group document. the first criteria should be that the contents of the draft and the requirements behind it don't conflict with the sip standard itself. a lot would need to changed in the bis in order to avoid the current conflicts. so go ahead and get that done first and then try to make the path header a working group document. or may be things have changed and now it is only money that speaks like we were able to read from a very frank posting earlier this week. may be our area directors can give us some guidance here? -- 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 daemon@optimus.ietf.org Sat Mar 2 08:38:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00033 for ; Sat, 2 Mar 2002 08:38:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17168 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 08:38:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15125; Sat, 2 Mar 2002 07:30:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15088 for ; Sat, 2 Mar 2002 07:30:49 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29331 for ; Sat, 2 Mar 2002 07:30:46 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g22CTjS02196; Sat, 2 Mar 2002 06:29:45 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g22CThs21563; Sat, 2 Mar 2002 06:29:43 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g22CThE14122; Sat, 2 Mar 2002 07:29:43 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 07:29:43 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037498@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'jh@lohi.eng.song.fi'" , "Rosen, Brian" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item Date: Sat, 2 Mar 2002 07:29:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Saturday, March 02, 2002 2:30 AM > To: Rosen, Brian > Cc: 'sip@ietf.org' > Subject: [Sip] Path to Working Group Item > > > Rosen, Brian writes: > > > There has been considerable discussion on the PATH header > on the list > > indicating more than significant interest to consider it a working > > group item. Are there any objections? > > the number of people (in this case the mobile gang) interested in > something should not be the only criteria of making that > something a sip > working group document. the first criteria should be that > the contents > of the draft and the requirements behind it don't conflict > with the sip > standard itself. You now what the requirements are. Suggest alternatives that *address* those requirements without breaking SIP, which you haven't done. But opted to cry wolf. Your only alternative has been to discount the requirements. I suggest you switch to the mobile world and get a better comprehension of how things work. Then we can talk. > > a lot would need to changed in the bis in order to avoid the current > conflicts. so go ahead and get that done first and then try > to make the > path header a working group document. or may be things have > changed and > now it is only money that speaks like we were able to read from a very > frank posting earlier this week. > I though it has been like that for the last 20 centuries. Nothing has changed. > may be our area directors can give us some guidance here? > > -- juha > > George Foti Ericsson Canada > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 2 08:44:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00102 for ; Sat, 2 Mar 2002 08:44:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17245 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 08:44:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15618; Sat, 2 Mar 2002 07:45:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15587 for ; Sat, 2 Mar 2002 07:45:52 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29645 for ; Sat, 2 Mar 2002 07:45:48 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16h8tX-00062s-00; Sat, 02 Mar 2002 14:45:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15488.51579.504863.337657@harjus.eng.song.fi> Date: Sat, 2 Mar 2002 14:45:47 +0200 To: "George Foti (LMC)" Cc: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037498@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C037498@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > You now what the requirements are. Suggest alternatives that *address* those > requirements without breaking SIP, which you haven't done. But opted to cry > wolf. Your only alternative has been to discount the requirements. that is not true. i have suggested that you use three things instead of the path header: - dhcp to locate the proxy of the visited network - dns with load balancing to figure out the proxy of the home network - loose source routing to get the requests to the home network and i haven't heard of any *convincing* arguments why that is not enough. the only requirement i remember discounting is pinning of a particular home proxy, which i consider a bad idea in general. load balancing helps to reduce the load of the entry proxies which can then route the request further, if necessary, to a particular service proxy. what comes to the requirements in general, i don't think that the sip working group should take the 3gpp requirements as given from top down by your gods, but should be allowed to consider first if they make any sense. -- 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 daemon@optimus.ietf.org Sat Mar 2 09:00:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00246 for ; Sat, 2 Mar 2002 09:00:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17827 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 09:00:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16471; Sat, 2 Mar 2002 08:14:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16441 for ; Sat, 2 Mar 2002 08:14:19 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29888 for ; Sat, 2 Mar 2002 08:14:18 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g22DDHS06117; Sat, 2 Mar 2002 07:13:17 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g22DDHL27143; Sat, 2 Mar 2002 07:13:17 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g22DDGE14560; Sat, 2 Mar 2002 08:13:16 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 08:13:43 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037499@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'jh@lohi.eng.song.fi'" Cc: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item Date: Sat, 2 Mar 2002 08:13:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Saturday, March 02, 2002 7:46 AM > To: George Foti (LMC) > Cc: Rosen, Brian; 'sip@ietf.org' > Subject: RE: [Sip] Path to Working Group Item > > > George Foti (LMC) writes: > > > You now what the requirements are. Suggest alternatives > that *address* those > > requirements without breaking SIP, which you haven't done. > But opted to cry > > wolf. Your only alternative has been to discount the requirements. > > that is not true. i have suggested that you use three things > instead of > the path header: > > - dhcp to locate the proxy of the visited network Fine and thats what is being done in this case > - dns with load balancing to figure out the proxy of the home network > - loose source routing to get the requests to the home network > You misuderstood the requirement here. The proxy assigned to a suscriber at home is not static, not known apriori. It is rather dynamic and assigned only at registration. So DNS is not an option. As far as using loose source routing, than some entity, that is today statless, will have to become stateful to know where to loose route for each subscriber. In other words we bastardized the architecture. Now you may argue about the architecture, and thats okay, but doing it from the sidelines does not work. You need to be fully engaged to understand the architecture in the first place before you make claims that we rejected solutions purposly. > and i haven't heard of any *convincing* arguments why that is not > enough. > > the only requirement i remember discounting is pinning of a particular > home proxy, which i consider a bad idea in general. load balancing > helps to reduce the load of the entry proxies which can then route the > request further, if necessary, to a particular service proxy. > > what comes to the requirements in general, i don't think that the sip > working group should take the 3gpp requirements as given from top down > by your gods, but should be allowed to consider first if they make > any sense. > > -- 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 daemon@optimus.ietf.org Sat Mar 2 09:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00474 for ; Sat, 2 Mar 2002 09:21:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18381 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 09:21:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16557; Sat, 2 Mar 2002 08:21:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16526 for ; Sat, 2 Mar 2002 08:21:13 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29918 for ; Sat, 2 Mar 2002 08:21:11 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16h9Ro-00063Z-00; Sat, 02 Mar 2002 15:21:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15488.53704.71107.187982@harjus.eng.song.fi> Date: Sat, 2 Mar 2002 15:21:12 +0200 To: "George Foti (LMC)" Cc: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C037499@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C037499@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > You misuderstood the requirement here. The proxy assigned to a suscriber at > home is not static, not known apriori. It is rather dynamic and assigned > only at registration. So DNS is not an option. huh, then your requirements have even less to do with the sip protocol than i thought. the sip specs say that the proxy of a user can be found from the dsn using the srv records. now you say that that is not true. it would be really high time that you stop wasting the bandwidth on the SIP mailing list with these kinds of requirements. > You need to be fully engaged to understand the architecture in the first > place before you make claims that we rejected solutions purposly. for me it is enough that i try to understand the SIP architecture. yours is something very different and doesn't belong to this mailing list. -- 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 daemon@optimus.ietf.org Sat Mar 2 14:35:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03826 for ; Sat, 2 Mar 2002 14:35:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00440 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 14:35:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28339; Sat, 2 Mar 2002 13:54:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28308 for ; Sat, 2 Mar 2002 13:54:12 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03281 for ; Sat, 2 Mar 2002 13:54:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g22IsP6Y023491; Sat, 2 Mar 2002 13:54:25 -0500 (EST) Message-ID: <3C811FAA.F5C5D4F8@dynamicsoft.com> Date: Sat, 02 Mar 2002 13:53:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: "George Foti (LMC)" , "Rosen, Brian" , "'sip@ietf.org'" Subject: Re: [Sip] Path to Working Group Item References: <15488.51579.504863.337657@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit jh@lohi.eng.song.fi wrote: > > George Foti (LMC) writes: > > > You now what the requirements are. Suggest alternatives that > *address* those > > requirements without breaking SIP, which you haven't done. But opted > to cry > > wolf. Your only alternative has been to discount the requirements. > > that is not true. i have suggested that you use three things instead of > the path header: > > - dhcp to locate the proxy of the visited network > - dns with load balancing to figure out the proxy of the home network > - loose source routing to get the requests to the home network > > and i haven't heard of any *convincing* arguments why that is not > enough. Path fills two needs, and you have omitted the second one. The second one is so that INCOMING calls to me, can be routed from my home proxy through an intermediate proxy that needs to be visited. I think this is well within the scope of an extension to REGISTER, and I know of no other alternative to solve it. This is needed for any kind of visiting/roaming network where a local proxy needs to be visited for incoming calls. I would prefer to let us agree to adopt path as a work item, with the current draft as a starting point, and then we can continue to debate handling of outgoing calls. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sat Mar 2 15:07:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04200 for ; Sat, 2 Mar 2002 15:07:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01410 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 15:07:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00532; Sat, 2 Mar 2002 14:38:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00505 for ; Sat, 2 Mar 2002 14:38:12 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03881 for ; Sat, 2 Mar 2002 14:38:08 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hFKb-00066U-00; Sat, 02 Mar 2002 21:38:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15489.10785.323279.964564@harjus.eng.song.fi> Date: Sat, 2 Mar 2002 21:38:09 +0200 To: Jonathan Rosenberg Cc: "George Foti (LMC)" , "Rosen, Brian" , "'sip@ietf.org'" Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <3C811FAA.F5C5D4F8@dynamicsoft.com> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > Path fills two needs, and you have omitted the second one. The second > one is so that INCOMING calls to me, can be routed from my home proxy > through an intermediate proxy that needs to be visited. I think this is > well within the scope of an extension to REGISTER, and I know of no > other alternative to solve it. This is needed for any kind of > visiting/roaming network where a local proxy needs to be visited for > incoming calls. no i have not omitted that one. i proposed that if i'm visiting in a network xyz.com, then my home proxy can route incoming calls to the proxy of xyz.com that in turn knows where to forward the message within that network. -- 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 daemon@optimus.ietf.org Sat Mar 2 15:25:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04424 for ; Sat, 2 Mar 2002 15:25:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01806 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 15:25:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00850; Sat, 2 Mar 2002 14:57:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00819 for ; Sat, 2 Mar 2002 14:57:06 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04070 for ; Sat, 2 Mar 2002 14:57:02 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g22JttS10026; Sat, 2 Mar 2002 13:55:55 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g22JtsL19361; Sat, 2 Mar 2002 13:55:54 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g22JtsE18167; Sat, 2 Mar 2002 14:55:54 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Mar 2002 14:55:54 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03749B@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Jonathan Rosenberg'" , jh@lohi.eng.song.fi Cc: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item Date: Sat, 2 Mar 2002 14:55:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I am for it as a working item /gf > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, March 02, 2002 1:54 PM > To: jh@lohi.eng.song.fi > Cc: George Foti (LMC); Rosen, Brian; 'sip@ietf.org' > Subject: Re: [Sip] Path to Working Group Item > > > > > jh@lohi.eng.song.fi wrote: > > > > George Foti (LMC) writes: > > > > > You now what the requirements are. Suggest alternatives that > > *address* those > > > requirements without breaking SIP, which you haven't > done. But opted > > to cry > > > wolf. Your only alternative has been to discount the > requirements. > > > > that is not true. i have suggested that you use three > things instead of > > the path header: > > > > - dhcp to locate the proxy of the visited network > > - dns with load balancing to figure out the proxy of the > home network > > - loose source routing to get the requests to the home network > > > > and i haven't heard of any *convincing* arguments why that is not > > enough. > > Path fills two needs, and you have omitted the second one. The second > one is so that INCOMING calls to me, can be routed from my home proxy > through an intermediate proxy that needs to be visited. I > think this is > well within the scope of an extension to REGISTER, and I know of no > other alternative to solve it. This is needed for any kind of > visiting/roaming network where a local proxy needs to be visited for > incoming calls. > > I would prefer to let us agree to adopt path as a work item, with the > current draft as a starting point, and then we can continue to debate > handling of outgoing calls. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sat Mar 2 18:22:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06232 for ; Sat, 2 Mar 2002 18:22:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07773 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 18:22:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07325; Sat, 2 Mar 2002 18:02:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07296 for ; Sat, 2 Mar 2002 18:02:12 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06137 for ; Sat, 2 Mar 2002 18:02:08 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g22N1fd16523 for ; Sat, 2 Mar 2002 15:01:41 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACO00408; Sat, 2 Mar 2002 15:01:40 -0800 (PST) Date: Sat, 2 Mar 2002 14:59:56 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] re: Path as WG item Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Juha, Assume: REGISTER sip:home.org SIP/2.0 To: sip:user@home.org From: sip:user@home.org Are you suggesting: 1) Contact: 2) Contact: with an additional registration to xyz.com (if so, what credentials would I use to authenticate my request?) 3) something else thanks, -rohan > Path fills two needs, and you have omitted the second one. The second > one is so that INCOMING calls to me, can be routed from my home proxy > through an intermediate proxy that needs to be visited. I think this is > well within the scope of an extension to REGISTER, and I know of no > other alternative to solve it. This is needed for any kind of > visiting/roaming network where a local proxy needs to be visited for > incoming calls. no i have not omitted that one. i proposed that if i'm visiting in a network xyz.com, then my home proxy can route incoming calls to the proxy of xyz.com that in turn knows where to forward the message within that network. -- 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 daemon@optimus.ietf.org Sat Mar 2 18:22:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06248 for ; Sat, 2 Mar 2002 18:22:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07787 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 18:22:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07377; Sat, 2 Mar 2002 18:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07347 for ; Sat, 2 Mar 2002 18:02:25 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06139 for ; Sat, 2 Mar 2002 18:02:21 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g22N1Dl30980; Sat, 2 Mar 2002 17:01:13 -0600 Message-ID: <016701c1c23e$2b8c7230$133fed0c@C1893415A> From: "Dean Willis" To: , "Jonathan Rosenberg" Cc: "George Foti \(LMC\)" , "Rosen, Brian" , References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Sat, 2 Mar 2002 17:01:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha said: > no i have not omitted that one. i proposed that if i'm visiting in a > network xyz.com, then my home proxy can route incoming calls to the > proxy of xyz.com that in turn knows where to forward the message within > that network. Foair enough. How does the home proxy know that you're visiting xyz.com and to route incoming calls to you care of xyz? Two proposals have been put forward: 1) xyz.com's proxy edits your REGISTER message such that your Contact: becomes @xyz.com and then maintains the state needed to make that work for you in the future. 2) xyz.com's proxy adds itself to some sort of "record route" on the REGISTER so that your home proxy can route back through it. #1 seems to be conflict with some approaches to e2e message integrity and requires registration-stafeulnes at the xyz.com proxy, which is an intermediate node that may otherwise not need to be registration-stateful. #2 doesn't seem to break integrity protection and keeps all state at the registrar or UA, which are by definition registration-stateful anyhow. Do you have another workable alternative to propose? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 2 18:51:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06571 for ; Sat, 2 Mar 2002 18:51:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08734 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 18:51:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08431; Sat, 2 Mar 2002 18:33:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08400 for ; Sat, 2 Mar 2002 18:33:50 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06367 for ; Sat, 2 Mar 2002 18:33:46 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g22NXJE10892 for ; Sat, 2 Mar 2002 15:33:19 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACO00490; Sat, 2 Mar 2002 15:33:18 -0800 (PST) Date: Sat, 2 Mar 2002 15:31:34 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Consensus poll on draft-ietf-sip-privacy-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, The SIP chairs asked me to poll the group to see how much consensus (or lack thereof) we have on the current text in the -04 privacy draft (available on the supplemental web site). This draft has been a working group item for long time, and most of the recent list discussion has been about extensibility and applicability. Please provide your feedback quickly so the SIP chairs can gauge the consensus of the group. Do you think this document is ready for working group last call? If not, please briefly describe why not. Would you object to publication of this document with the draft content essentially intact? (assume a thorough NITS review, possible formatting or readability changes). If so, please summarize your objections (briefly). Many thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 2 20:15:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07064 for ; Sat, 2 Mar 2002 20:15:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11430 for sip-archive@odin.ietf.org; Sat, 2 Mar 2002 20:15:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10603; Sat, 2 Mar 2002 19:50:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10573 for ; Sat, 2 Mar 2002 19:50:05 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-217-199-174.dsl.rcsntx.swbell.net [64.217.199.174]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06920 for ; Sat, 2 Mar 2002 19:49:55 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g230F7X25723; Sat, 2 Mar 2002 18:15:22 -0600 Message-ID: <3C8175C9.B8772BC4@dasecurenetworks.com> Date: Sat, 02 Mar 2002 19:00:57 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] Consensus poll on draft-ietf-sip-privacy-04.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I believe that this draft covers alot of necessary and relevant areas for SIP regarding interdomain traffic and provides a good framework to address the issues of topology hiding, call ID and privacy as defined by the draft. Many vendors are developing methods that can provide the anonymizing features mentioned in this draft today using either B2BUA functionality or Firewall ALG functionality that is SIP capable and which provides the functionality of topology hiding for both media and SIP. I am in support of this draft. Chris. Rohan Mahy wrote: > > Hi Folks, > > The SIP chairs asked me to poll the group to see how much consensus (or > lack thereof) we have on the current text in the -04 privacy draft > (available on the supplemental web site). > > This draft has been a working group item for long time, and most of the > recent list discussion has been about extensibility and applicability. > Please provide your feedback quickly so the SIP chairs can gauge the > consensus of the group. > > Do you think this document is ready for working group last call? > If not, please briefly describe why not. > > Would you object to publication of this document with the draft content > essentially intact? (assume a thorough NITS review, possible formatting > or readability changes). If so, please summarize your objections > (briefly). > > Many thanks, > -rohan > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 01:59:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11603 for ; Sun, 3 Mar 2002 01:59:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA03025 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 01:59:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02638; Sun, 3 Mar 2002 01:34:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02607 for ; Sun, 3 Mar 2002 01:34:43 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11473 for ; Sun, 3 Mar 2002 01:33:14 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hPYV-0006LC-00; Sun, 03 Mar 2002 08:33:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15489.50086.993050.645336@harjus.eng.song.fi> Date: Sun, 3 Mar 2002 08:33:10 +0200 To: "Dean Willis" Cc: "Jonathan Rosenberg" , "George Foti \(LMC\)" , "Rosen, Brian" , Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <016701c1c23e$2b8c7230$133fed0c@C1893415A> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Foair enough. How does the home proxy know that you're visiting xyz.com and > to route incoming calls to you care of xyz? by checking from the registrar where my contact points to. my home proxy can make a reverse lookup if i haven't registered with a domain name in the contact or, better, the registrar does it before it enters the contact in its database. jonathan, i start to suspect that also your company has vested interest in 3gpp :-). also the other "fathers" of the sip protocol that have previously very vigorously protected sip from unnecessary extensions have been surprisingly quiet on this one. -- 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 daemon@optimus.ietf.org Sun Mar 3 02:08:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17140 for ; Sun, 3 Mar 2002 02:08:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA03549 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 02:08:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02923; Sun, 3 Mar 2002 01:55:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02892 for ; Sun, 3 Mar 2002 01:55:03 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11553 for ; Sun, 3 Mar 2002 01:55:01 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g236s1l00786; Sun, 3 Mar 2002 00:54:01 -0600 Message-ID: <003901c1c280$355c2c00$133fed0c@C1893415A> From: "Dean Willis" To: Cc: References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Sun, 3 Mar 2002 00:54:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha writes: > Dean Willis writes: > > > Foair enough. How does the home proxy know that you're visiting xyz.com and > > to route incoming calls to you care of xyz? > > by checking from the registrar where my contact points to. my home > proxy can make a reverse lookup if i haven't registered with a domain > name in the contact or, better, the registrar does it before it enters > the contact in its database. Ok, please pretend I'm stupid (shouldn't be hard, might even be true) and explain this in very small words. Here's a real scenario, called "Dean's House". My SIP phone (a lovely antique 3Com) has an address of 63.64.250.84 which it was assigned by a nearby DHCP server. So it registers with a Contact: dwillis@63.64.250.84. There's a proxy at 63.64.250.83 that I need incoming INVITES to traverse. Let's say I register with a remote registrar, like the one at "dynamicsoft.com" (63.110.3.106). How the heck does the registrar know about the proxy at 63.64.250.83? Please feel free to examine the DNS, do reverse lookups, etc. in order to answer the question. Keep in mind that this is a real-world scenario, with valid addresses, real equipment, and with the DNS limitations imposed by at least two different real-life ISPs. .-- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 04:06:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20531 for ; Sun, 3 Mar 2002 04:06:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07091 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 04:06:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04590; Sun, 3 Mar 2002 02:40:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA04558 for ; Sun, 3 Mar 2002 02:40:06 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19994 for ; Sun, 3 Mar 2002 02:40:03 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hQb7-0006Lr-00; Sun, 03 Mar 2002 09:39:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15489.54093.327411.43727@harjus.eng.song.fi> Date: Sun, 3 Mar 2002 09:39:57 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <003901c1c280$355c2c00$133fed0c@C1893415A> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > My SIP phone (a lovely antique 3Com) has an address of 63.64.250.84 which it > was assigned by a nearby DHCP server. > > So it registers with a Contact: dwillis@63.64.250.84. There's a proxy at > 63.64.250.83 that I need incoming INVITES to traverse. > > Let's say I register with a remote registrar, like the one at > "dynamicsoft.com" (63.110.3.106). > > How the heck does the registrar know about the proxy at 63.64.250.83? dynamicsoft's registrar doesn't need to know about the proxy of the domain you are visiting. it just converts your contact addressdwillis@63.64.250.84 into domain name, e.g., dwillis@host.visitedDomain and enters it in its database. when someone tries to invite you at dwillis@dynamicsoft.com, the call gets routed using normal rules to the proxy of dynamicsoft.com. the proxy of dynamicsoft.com then asks the registrar where you are registered at and turns the invite to dwillis@dynamicsoft.com into invite to dwillis@host.visitedDomain. that invite will then get routed EXACTLY as the book says, i.e., the proxy of dynamicsoft queries dns to find out the proxy of host.visitedDomain, and will forward the invite there. that proxy will then have local knowledge on how to reach you. -- 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 daemon@optimus.ietf.org Sun Mar 3 08:52:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23417 for ; Sun, 3 Mar 2002 08:52:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA15231 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 08:52:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14447; Sun, 3 Mar 2002 08:25:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14416 for ; Sun, 3 Mar 2002 08:25:33 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23110 for ; Sun, 3 Mar 2002 08:25:31 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g23DPWh06316 for ; Sun, 3 Mar 2002 07:25:32 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g23DPWL05587 for ; Sun, 3 Mar 2002 07:25:32 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g23DPVE28176 for ; Sun, 3 Mar 2002 08:25:31 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Mar 2002 08:25:59 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03749D@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Sun, 3 Mar 2002 08:25:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Question on Events-04 draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Adam, When would one in practice use probation as a reason code. Is this a graceful server failure case? Rgds/gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 09:47:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24082 for ; Sun, 3 Mar 2002 09:47:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16900 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 09:46:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16723; Sun, 3 Mar 2002 09:32:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16692 for ; Sun, 3 Mar 2002 09:32:47 -0500 (EST) Received: from hotmail.com (f133.law14.hotmail.com [64.4.21.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23914 for ; Sun, 3 Mar 2002 09:32:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Mar 2002 06:32:16 -0800 Received: from 129.107.62.219 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 03 Mar 2002 14:32:16 GMT X-Originating-IP: [129.107.62.219] From: "SIP SIP" To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] Path to Working Group Item Date: Sun, 03 Mar 2002 14:32:16 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2002 14:32:16.0523 (UTC) FILETIME=[3796E5B0:01C1C2C0] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi does any body know bout any good book on SIP hich covers all the areas of the working of SIP.let me know. >From: Jonathan Rosenberg >To: jh@lohi.eng.song.fi >CC: "George Foti (LMC)" , "Rosen, Brian" >, "'sip@ietf.org'" >Subject: Re: [Sip] Path to Working Group Item >Date: Sat, 02 Mar 2002 13:53:30 -0500 > > > >jh@lohi.eng.song.fi wrote: > > > > George Foti (LMC) writes: > > > > > You now what the requirements are. Suggest alternatives that > > *address* those > > > requirements without breaking SIP, which you haven't done. But opted > > to cry > > > wolf. Your only alternative has been to discount the requirements. > > > > that is not true. i have suggested that you use three things instead of > > the path header: > > > > - dhcp to locate the proxy of the visited network > > - dns with load balancing to figure out the proxy of the home network > > - loose source routing to get the requests to the home network > > > > and i haven't heard of any *convincing* arguments why that is not > > enough. > >Path fills two needs, and you have omitted the second one. The second >one is so that INCOMING calls to me, can be routed from my home proxy >through an intermediate proxy that needs to be visited. I think this is >well within the scope of an extension to REGISTER, and I know of no >other alternative to solve it. This is needed for any kind of >visiting/roaming network where a local proxy needs to be visited for >incoming calls. > >I would prefer to let us agree to adopt path as a work item, with the >current draft as a starting point, and then we can continue to debate >handling of outgoing calls. > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (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 _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 12:13:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26357 for ; Sun, 3 Mar 2002 12:13:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA22296 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 12:13:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21063; Sun, 3 Mar 2002 11:54:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21032 for ; Sun, 3 Mar 2002 11:54:52 -0500 (EST) Received: from hotmail.com (f133.law14.hotmail.com [64.4.21.133]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26149 for ; Sun, 3 Mar 2002 11:54:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Mar 2002 08:54:20 -0800 Received: from 129.107.63.11 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 03 Mar 2002 16:54:20 GMT X-Originating-IP: [129.107.63.11] From: "SIP SIP" To: fredsherman1@yahoo.com Cc: sip@ietf.org Subject: Re: [Sip] Path to Working Group Item Date: Sun, 03 Mar 2002 16:54:20 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2002 16:54:20.0961 (UTC) FILETIME=[108CE910:01C1C2D4] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, what research is going on SIP othe wireless side.Any organizations working on that >From: Fred Sherman >To: SIP SIP >Subject: Re: [Sip] Path to Working Group Item >Date: Sun, 3 Mar 2002 07:00:59 -0800 (PST) > >"SIP Demystified" Gonzalo Camarillo >McGraw-Hill > >--- SIP SIP wrote: > > > > > > Hi does any body know bout any good book on SIP hich > > covers all the areas of > > the working of SIP.let me know. > > >From: Jonathan Rosenberg > > >To: jh@lohi.eng.song.fi > > >CC: "George Foti (LMC)" , > > "Rosen, Brian" > > >, "'sip@ietf.org'" > > > > >Subject: Re: [Sip] Path to Working Group Item > > >Date: Sat, 02 Mar 2002 13:53:30 -0500 > > > > > > > > > > > >jh@lohi.eng.song.fi wrote: > > > > > > > > George Foti (LMC) writes: > > > > > > > > > You now what the requirements are. Suggest > > alternatives that > > > > *address* those > > > > > requirements without breaking SIP, which you > > haven't done. But opted > > > > to cry > > > > > wolf. Your only alternative has been to > > discount the requirements. > > > > > > > > that is not true. i have suggested that you use > > three things instead of > > > > the path header: > > > > > > > > - dhcp to locate the proxy of the visited > > network > > > > - dns with load balancing to figure out the > > proxy of the home network > > > > - loose source routing to get the requests to > > the home network > > > > > > > > and i haven't heard of any *convincing* > > arguments why that is not > > > > enough. > > > > > >Path fills two needs, and you have omitted the > > second one. The second > > >one is so that INCOMING calls to me, can be routed > > from my home proxy > > >through an intermediate proxy that needs to be > > visited. I think this is > > >well within the scope of an extension to REGISTER, > > and I know of no > > >other alternative to solve it. This is needed for > > any kind of > > >visiting/roaming network where a local proxy needs > > to be visited for > > >incoming calls. > > > > > >I would prefer to let us agree to adopt path as a > > work item, with the > > >current draft as a starting point, and then we can > > continue to debate > > >handling of outgoing calls. > > > > > >-Jonathan R. > > > > > >-- > > >Jonathan D. Rosenberg, Ph.D. 72 Eagle > > Rock Avenue > > >Chief Scientist First Floor > > >dynamicsoft East > > Hanover, NJ 07936 > > >jdrosen@dynamicsoft.com FAX: (973) > > 952-5050 > > >http://www.jdrosen.net PH: (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 > > > > > > >_________________________________________________________________ > > MSN Photos is the easiest way to share and print > > your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Sports - sign up for Fantasy Baseball >http://sports.yahoo.com _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Sun Mar 3 12:44:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26974 for ; Sun, 3 Mar 2002 12:44:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23459 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 12:44:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22574; Sun, 3 Mar 2002 12:22:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22540 for ; Sun, 3 Mar 2002 12:22:17 -0500 (EST) Received: from hotmail.com (f231.law14.hotmail.com [64.4.21.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26448 for ; Sun, 3 Mar 2002 12:22:13 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Mar 2002 09:21:46 -0800 Received: from 129.107.63.11 by lw14fd.law14.hotmail.msn.com with HTTP; Sun, 03 Mar 2002 17:21:46 GMT X-Originating-IP: [129.107.63.11] From: "SIP SIP" To: sip@ietf.org Date: Sun, 03 Mar 2002 17:21:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Mar 2002 17:21:46.0612 (UTC) FILETIME=[E56F5340:01C1C2D7] Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If the media streams tke a different way than the signalling messages in SIp how can the security of the media stream be guaranteed. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Sun Mar 3 12:46:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27007 for ; Sun, 3 Mar 2002 12:46:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23491 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 12:46:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22621; Sun, 3 Mar 2002 12:23:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22596 for ; Sun, 3 Mar 2002 12:23:49 -0500 (EST) Received: from lakemtao02.cox.net (mtao2.east.cox.net [68.1.17.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26467 for ; Sun, 3 Mar 2002 12:23:45 -0500 (EST) Received: from cox.net ([68.2.76.132]) by lakemtao02.cox.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with ESMTP id <20020303172316.YIDH20705.lakemtao02.cox.net@cox.net> for ; Sun, 3 Mar 2002 12:23:16 -0500 Message-ID: <3C825BE2.EC0A37A5@cox.net> Date: Sun, 03 Mar 2002 10:22:42 -0700 From: Michael Purcell Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: RE:Dialog Tunnelling == bad (Was: [SIP] Event ID) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Where can I find more on this "session dialog" concept by encompassing all tunnelled sub-dialogs? -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Tuesday, February 19, 2002 3:57 PM To: 'Adam Roach'; jdrosen@dynamicsoft.com; rsparks@dynamicsoft.com Cc: sip@ietf.org Subject: Dialog Tunnelling == bad (Was: [SIP] Event ID) Hi all, My food for thought for the day: This is not so much an objection to the Event header Id parameter but I wanted to raise my concern that this idea of tunnelling subscriptions (or other sub-dialog, e.g. REFERs) through INVITE initiated dialogs (or other any dialog) - I believe it is running in the wrong direction. I completely agree with Jonathan that we need to separate session state from sip dialog state. I believe you are trying to accomplish this with your concept of extending a "session dialog" concept by encompassing all tunnelled sub-dialogs. I believe this is analogous to trying to implement call-control by doing "funky" stuff in B2BUA's using a single dialog - e.g. DTMF in INFO - it works _very_ well for some application models but falls down quickly when you try to use MUTLIPLE DIALOGS! This is why it is so hard to kick DTMF in INFO - it works so well for the B2BUA model but falls apart when you start using REFER/Replaces/etc/etc. The separation of session state from dialog state should revolve around SESSIONs being defined in terms of CONVERSATION-SPACEs. Now conversation spaces revolve around the call-control primitives and MULTIPLE dialogs. Encouraging REFER's and SUBSCRIBE's to be tunnelled through INVITE initiated dialogs makes it very difficult to work with conversation spaces. The reason for this is that you have now muddied the association between the original INVITE dialog and existence of the residual dialog where the dialog would not otherwise be in the conversation-space. This approach simply complicates conversation spaces and the use of call-control primitives such as REFER/Replaces/Join, etc - an area which is already complicated enough. So let me give a couple of rough examples. For starters the conversation space model must be rewritten to differentiated between what is a "real conversation space dialog" participant and what is a "residual dialog that has been terminated but is still hanging around because it is acting as a conduit for a SUBSCRIBE or REFER" dialog. This is a TERRIBLE complication to the conversation space concept - perhaps terminally. For instance, unless you redefine the conversation space very carefully, a INVITE-initiated dialog that is currently only being used by a subscription to a conversation-space will stop a conversation space (as currently written) from ending. The conversation-space must be redefined not in terms of dialogs but in terms of sub-dialogs which incidentally usually won't even exist when the INVITE dialog is first received. Obviously this is not an unsolvable problem but it shows the tip of the iceberg in terms of wide ranging complications introduced. Likewise, the handling of all call-control primitives such as Replace/Join/etc etc is complicated by the fact that an INVITE-initiated dialog may exist but its no longer being used for an INVITE sip session. So what are we trying to accomplish? We are trying to guarantee that if a path for an INVITE dialog is established, then subsequent dialogs from some entity along that call path can also establish a new dialog fairly reliably. So the requirement is that the network and UA treats the new dialog identically for routing purposes but is recognized as *NOT* the same dialog (so that it won't be torn down at the same time). This is a problem with backward compatibility but I feel it is better than going down the other road of sub-dialogs!! Shouldn't we be working not making sure that we put together guidelines so that Route headers are portable/usable by "companion dialogs" from entities on the same call path. IMO, this is the direction we should be heading and not to the B2BUA infested waters of sub-dialogs. I would say even that (perhaps counter-intuitively) backwards compatibly is MORE of a problem with this new sub-dialog concept than with trying to do things correctly with Route headers. At least you know if a set of pre-loaded Route header fail when everything has its own dialog (and probably has a good chance of working even with today's proxies); however, when trying to have multiple sub-dialogs use the same call transaction id you have NO idea whether a proxy will drop all sub-dialogs when the first BYE comes along! I think that is something worth thinking about! Cheers, Robert. > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 18 February 2002 23:31 > To: 'Fairlie-Cuninghame, Robert'; Adam Roach > Cc: 'sip@ietf.org' > Subject: RE: Event ID (was RE: Events Last Call.) > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > > Now I don't think this is necessarily contrary to the Id > > parameter but the > > way you justify the complexity added by the Id parameter scares me. > > Basically, if you are solving the problem for an UA endpoint > > delivering a > > subscription through an existing INVITE dialog then IMO you > must also > > address how a proxy can also accomplish this in an equally > guaranteed > > manner. > > I hat B2BUAs at least as much as you do, and fully understand your > objection. As soon as you propose something that works, I'll > incorporate it. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 12:47:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27023 for ; Sun, 3 Mar 2002 12:47:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23505 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 12:47:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22489; Sun, 3 Mar 2002 12:19:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22464 for ; Sun, 3 Mar 2002 12:19:08 -0500 (EST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26409 for ; Sun, 3 Mar 2002 12:19:03 -0500 (EST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g23HEm217219 for ; Sun, 3 Mar 2002 19:14:48 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Mar 2002 19:18:59 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Date: Sun, 3 Mar 2002 19:18:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Subject: [Sip] Question bis 07: "response retransmissions" for none-INVITE trans action Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, bis 07 section 17.1.2.2 for none INVITE Client Transaction says: Once the client transaction enters the "Completed" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The "Completed" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for unreliable transports). As far as I understand the only response retransmissions are for ACK in INVITE transaction. What is the meaning of "response retransmissions" for none-INVITE transaction ? Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 16:19:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29842 for ; Sun, 3 Mar 2002 16:19:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01596 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 16:19:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00424; Sun, 3 Mar 2002 15:46:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00393 for ; Sun, 3 Mar 2002 15:46:56 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29585 for ; Sun, 3 Mar 2002 15:46:53 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g23KkNl12352; Sun, 3 Mar 2002 14:46:23 -0600 Message-ID: <000b01c1c2f4$7b986c00$133fed0c@C1893415A> From: "Dean Willis" To: Cc: , Date: Sun, 3 Mar 2002 14:46:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WG adoption of Update method Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Based on list discussions, I believe we have working group consensus to adopt the UPDATE method as an effort of the SIP working group. This work is addressed in our current charter under the "preconditions" charter item and is required to support the April milestone for delivery of the manyfolks-resource specification to IESG. See: http://search.ietf.org/internet-drafts/draft-ietf-sip-update-00.txt -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 16:56:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00271 for ; Sun, 3 Mar 2002 16:56:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03038 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 16:56:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01275; Sun, 3 Mar 2002 16:08:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01246 for ; Sun, 3 Mar 2002 16:08:24 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29766 for ; Sun, 3 Mar 2002 16:08:22 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g23L7Nl12511; Sun, 3 Mar 2002 15:07:23 -0600 Message-ID: <002101c1c2f7$6951e550$133fed0c@C1893415A> From: "Dean Willis" To: Cc: References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A><15489.50086.993050.645336@harjus.eng.song.fi><003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Sun, 3 Mar 2002 15:07:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: To: "Dean Willis" Cc: Sent: Sunday, March 03, 2002 1:39 AM Subject: Re: [Sip] Path to Working Group Item > Dean Willis writes: > > > My SIP phone (a lovely antique 3Com) has an address of 63.64.250.84 which it > > was assigned by a nearby DHCP server. > > > > So it registers with a Contact: dwillis@63.64.250.84. There's a proxy at > > 63.64.250.83 that I need incoming INVITES to traverse. > > > > Let's say I register with a remote registrar, like the one at > > "dynamicsoft.com" (63.110.3.106). > > > > How the heck does the registrar know about the proxy at 63.64.250.83? > > dynamicsoft's registrar doesn't need to know about the proxy of the > domain you are visiting. it just converts your contact > addressdwillis@63.64.250.84 into domain name, e.g., > dwillis@host.visitedDomain and enters it in its database. > > when someone tries to invite you at dwillis@dynamicsoft.com, the call > gets routed using normal rules to the proxy of dynamicsoft.com. the > proxy of dynamicsoft.com then asks the registrar where you are > registered at and turns the invite to dwillis@dynamicsoft.com into > invite to dwillis@host.visitedDomain. > > that invite will then get routed EXACTLY as the book says, i.e., the > proxy of dynamicsoft queries dns to find out the proxy of > host.visitedDomain, and will forward the invite there. that proxy will > then have local knowledge on how to reach you. > > -- juha Methinks you have a very different understanding of SIP and DNS than I do. Here's the proof, which you apparently didn't bother to research (despite theoretically having all the necessary knowledge available) before responding. In this test case, if the dynamicsoft.com proxy were to do a reverse lookup on 63.64.250.84, it would find that that this address resolves as "dwillis3.directlink.net". In this case, directlink.net is my ISP. They won't delegate PTR records so that I can handle the DNS. This is pretty much normal -- ISPs have little interest in doing DNS right for smaller customers like me. I had to fight them to get a name that was even that close -- they started out with something like dlci2184-3.dallas.directlink.net. Furthermore, Directlink doesn't run a proxy, and if they did, I still wouldn't trust them to run MY firewall proxy. So, your proposed mechanism completely doesn't work in an ordinary, real-world case affecting a real-live-not-completely-ignorant end user (me), and it's not likely to work. That's why we have the Path proposal, and I believe this pretty much wraps up the discussion. On a related note, if you're reading the service location procedures this way in bis-09, we didn't clean the language up as much as we thought, because I think you missed the point completely. Following your example, and assuming the registrar was stupid enough to try and convert the Contact IP address into a hostname (which they normally don't do), it still wouldn't look for visitedDomain. Instead it would look for service records for host.visitedDomain, which of course aren't there, as visitedDomain has no idea that "host" is currently being used as a SIP UA and couldn't be bothered to put that information into DNS even if it were. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 17:07:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00381 for ; Sun, 3 Mar 2002 17:07:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04002 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 17:07:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01725; Sun, 3 Mar 2002 16:21:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01696 for ; Sun, 3 Mar 2002 16:21:28 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29881 for ; Sun, 3 Mar 2002 16:21:25 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hdQ5-0006WH-00; Sun, 03 Mar 2002 23:21:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15490.37845.661770.900419@harjus.eng.song.fi> Date: Sun, 3 Mar 2002 23:21:25 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <002101c1c2f7$6951e550$133fed0c@C1893415A> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> <002101c1c2f7$6951e550$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit dean, i don't see how your example relates to the 3gpp requirements, which i though was the topic of this thread. they do have a proxy at the visited network and they can make sure that there exists an srv record for the visited domain. so my proposal covers they requirements without a path header. now you seem to be talking about something else, which i don't know what it is. -- 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 daemon@optimus.ietf.org Sun Mar 3 19:58:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01822 for ; Sun, 3 Mar 2002 19:58:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10412 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 19:58:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08852; Sun, 3 Mar 2002 19:24:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08822 for ; Sun, 3 Mar 2002 19:24:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01574 for ; Sun, 3 Mar 2002 19:24:38 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g240O9d26201; Sun, 3 Mar 2002 16:24:09 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACE05154; Sun, 3 Mar 2002 16:24:18 -0800 (PST) From: "David R. Oran" To: "'Drage, Keith \(Keith\)'" , Subject: RE: [Sip] Path header: Independent operation in each direction, or common o peration for both directions Date: Sun, 3 Mar 2002 19:24:02 -0500 Organization: Cisco Systems Message-ID: <059101c1c312$e55b5440$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439E922@en0033exch001u.uk.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit As a somewhat contrived example, what if I delegate my incoming call screening to a different domain than I delegate my outgoing call handling? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Drage, Keith (Keith) > Sent: Monday, February 25, 2002 5:44 AM > To: 'sip@ietf.org' > Subject: [Sip] Path header: Independent operation in each > direction, or common o peration for both directions > > > I am breaking out the issues that I think need more > discussion relating to the proposed Path header. This is the > first of those mails. > > Currently the mechanism specified for 3GPP looks very like > Record-Route and it therefore collects the URLs of the > proxies that wish to be on the path for future transactions > by use of the header within the REGISTER request, and the > response is merely a transport mechanism of the gathered > information back to the UA from the registrar. > > This means that proxies so identified are intended to be in > the path for both incoming and outgoing requests, as there is > no means of distinguishing the two independently (or at least > not with a single header, or separate lists within the common header). > > The mechanism proposed in Deans draft allows independent > gathering of information in each direction; a proxy that > wishes to be on the path in both incoming and outgoing > directions must insert its URL in both the request and the > response. This loses the commonality of the procedures with > Record-Route. > > While both mechanisms work, having discussed the requirements > with a limited set of people, we cannot think of a situation > whereby a proxy would want to be on the incoming path and not > on the outgoing path, and vice-versa. Certainly in 3GPP, the > requirement needs to apply in both directions. Therefore the > real question is are we developing a solution that does more > that the requirements need, and therefore losing the > commonality with Record-Route as a result. > > [While there may be advantages of code sharing with > Record-Route for implementations, I am thinking more of the > advantages to understanding the specification. People are > more likely to understand and implement Path correctly if it > works the same way as something else.] > > So, those who need operations independently in both > directions, can you shout up and give us some examples. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 20:19:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02011 for ; Sun, 3 Mar 2002 20:19:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA11518 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 20:19:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09554; Sun, 3 Mar 2002 19:32:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09489 for ; Sun, 3 Mar 2002 19:32:33 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01634; Sun, 3 Mar 2002 19:32:29 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g240Vxd28453; Sun, 3 Mar 2002 16:31:59 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACE05194; Sun, 3 Mar 2002 16:32:07 -0800 (PST) From: "David R. Oran" To: "'Peterson, Jon'" , "'Flemming Andreasen'" , "'Gonzalo Camarillo'" Cc: "'sip'" , "'mmusic'" , "'Fredrik Lindholm \(ERA\)'" , "'Jonathan Rosemberg'" , Subject: RE: [Sip] Removing security preconditions from manyfolks Date: Sun, 3 Mar 2002 19:31:54 -0500 Organization: Cisco Systems Message-ID: <059201c1c313$fd7d8060$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <70565611B164D511957A001083FCDD5601870100@VA02> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Peterson, Jon > Sent: Monday, February 25, 2002 5:12 PM > To: 'Flemming Andreasen'; Gonzalo Camarillo > Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; > wtm@research.att.com > Subject: RE: [Sip] Removing security preconditions from manyfolks > > > One of the reasons why you need a special preconditions flag > (and the rest of the manyfolks apparatus) for QoS is because > you use a separate protocol (like RSVP) to negotiate the > reserved path end-to-end. Nothing about SIP or SDP or RTP > would otherwise tell you that reservation of the path has > been expected or achieved. IMHO, this would be unwise, and > probably infeasible, for a security mechanism. The use of > sRTP e2e will be obvious to the respective user agents, for > example, and the parameters of the sRTP session should be > correlated easily to information in SDP or SIP so the UAs can > have verifiable expectations about the session's security. I > think all e2e media security mechanisms will probably need to > have these sorts of properties (regardless of whether or not > you use RTP, secure media will still be secured, and that > will always be obvious to the user agents). Therefore, I > think that a separate preconditions flag for security should > always be superfluous for any useful security mechanism. I > think we can ditch it. > This is not at all clear to me. What if I want to use IKE or Kerberos to do the key exchange? What if the key exchange is not in fact tied directly to the session signaling, but you need to verify via the call signaling that cached keys have not been thrown away? > That much said, I don't necessarily oppose the IANA > registration suggested by Flemming below, although I think as > a motivation for it we'd need to understand, generally > speaking, what sort of other preconditions people might find > desirable. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Sunday, February 24, 2002 9:42 PM > > To: Gonzalo Camarillo > > Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; > > wtm@research.att.com > > Subject: Re: [Sip] Removing security preconditions from manyfolks > > > > > > Not all media streams use RTP or SRTP, and there are other security > > mechanism than MIKEY. While I don't feel strongly about keeping the > > "security" precondition, I don't see much gained from removing it. > > Perhaps more importantly, since you are going to break the existing > > manyfolks-03 draft mechanism anyway, it would make sense to > make the > > preconditions extensible (with suitable IANA registration > procedures > > of course). > > > > -- Flemming > > > > > > Gonzalo Camarillo wrote: > > > > > Hi, > > > > > > we are thinking of removing security preconditions from > > manyfolks. Right > > > now manyfolks handles QoS and security preconditions. > However, with > > > MIKEY, this feature seems useless to establish secure channels. > > > > > > If somebody thinks that removing security preconditions > > from manyfolks > > > is a bad idea, please speak up. > > > > > > Regards, > > > > > > Gonzalo > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 > http://www.hut.fi/~gonzalo New > > > York, NY 10027 > > > USA > Gonzalo.Camarillo@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 > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 3 23:36:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05941 for ; Sun, 3 Mar 2002 23:36:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA19391 for sip-archive@odin.ietf.org; Sun, 3 Mar 2002 23:36:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17371; Sun, 3 Mar 2002 22:58:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17342 for ; Sun, 3 Mar 2002 22:58:35 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05099 for ; Sun, 3 Mar 2002 22:58:33 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g243vSl15024; Sun, 3 Mar 2002 21:57:28 -0600 Message-ID: <004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> From: "Dean Willis" To: Cc: References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A><15489.50086.993050.645336@harjus.eng.song.fi><003901c1c280$355c2c00$133fed0c@C1893415A><15489.54093.327411.43727@harjus.eng.song.fi><002101c1c2f7$6951e550$133fed0c@C1893415A> <15490.37845.661770.900419@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Sun, 3 Mar 2002 21:56:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit That's the point. This is a general SIP problem that we've been talking about for years. It just happens to apply to the 3G environment too. It's pretty reactionary to assume that a problem is not real just because it was also noticed by 3G. This is real, we're solving general problems, and the vast majority of the people who have historically contributed a great deal to SIP seem to agree. It seems that you are suggesting that 3G's implementation of SIP should work completely differently from regular SIP? That seems like a questionable idea to me. -- Dean ----- Original Message ----- From: To: "Dean Willis" Cc: Sent: Sunday, March 03, 2002 3:21 PM Subject: Re: [Sip] Path to Working Group Item > dean, > > i don't see how your example relates to the 3gpp requirements, which i > though was the topic of this thread. they do have a proxy at the visited > network and they can make sure that there exists an srv record for the > visited domain. so my proposal covers they requirements without a path > header. > > now you seem to be talking about something else, which i don't know what > it is. > > -- 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 daemon@optimus.ietf.org Mon Mar 4 01:36:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07465 for ; Mon, 4 Mar 2002 01:36:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA05769 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 01:36:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23396; Mon, 4 Mar 2002 01:00:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA23349 for ; Mon, 4 Mar 2002 01:00:00 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07150 for ; Mon, 4 Mar 2002 00:59:57 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hlVt-0006de-00; Mon, 04 Mar 2002 07:59:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.3421.688850.744507@harjus.eng.song.fi> Date: Mon, 4 Mar 2002 07:59:57 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> <002101c1c2f7$6951e550$133fed0c@C1893415A> <15490.37845.661770.900419@harjus.eng.song.fi> <004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > It seems that you are suggesting that 3G's implementation of SIP should work > completely differently from regular SIP? That seems like a questionable idea > to me. 3gpp is a closed community which will exactly define how their phone, registrar, or proxy will work and will specify it in their standards. so it would not be any hassle for them to say that a 3gpp registrar stores the contact information of visiting phones as domain names. this was the only new thing that i proposed and it would be purely an implementation issue not affecting ietf sip standards. but lets now get back to your new example, where (i think) you have been given a subnet of global ip addresses for your home or small business, but your isp is not willing to add an srv record for the domain *.dlci2184-3.dallas.directlink.net. that so if i have understood correctly, your case is this: SIP UA --- LAN --- FW/Proxy --- Internet --- Registrar and that would like to do is to make incoming calls to your ua to be routed via your fw/proxy. by the way, since you said that this is a real world example, where did you buy the FW/Proxy? i would like to buy one too, but haven't yet found anything that would suit the budged of a home/small business user. what you describe is a valid problem and luckily we already have a header that solves it. that header is called record-route. when you send your register message to your fw/proxy, that proxy, knowing that it needs to be on the path when someone calls you, adds a record-route header to the register message and forwards it to your registrar. your registrar then inserts the record route along with the contact address in its database. when someone calls you, the proxy of the registrar's domain adds the corresponding route header to the invite message and we are done. the only thing we thus need to do to solve this valid problem is to make a small change to the text of the bis regarding record routing of register messages. -- 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 daemon@optimus.ietf.org Mon Mar 4 02:07:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12573 for ; Mon, 4 Mar 2002 02:07:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07448 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 02:07:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04905; Mon, 4 Mar 2002 01:30:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04857 for ; Mon, 4 Mar 2002 01:30:04 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07394 for ; Mon, 4 Mar 2002 01:30:01 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hlz0-0006dr-00; Mon, 04 Mar 2002 08:30:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.5226.868652.473823@harjus.eng.song.fi> Date: Mon, 4 Mar 2002 08:30:02 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <002101c1c2f7$6951e550$133fed0c@C1893415A> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> <002101c1c2f7$6951e550$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit dean. even if i myself prefer the record-route solution to your problem,i still want to get back to your dns message, since your reply was full of misunderstandings. > Here's the proof, which you apparently didn't bother to research (despite > theoretically having all the necessary knowledge available) before > responding. the above is a bit nasty considering you first didn't seem to read or bother to understand my proposal. see below. > In this test case, if the dynamicsoft.com proxy were to do a reverse lookup > on 63.64.250.84, it would find that that this address resolves as > "dwillis3.directlink.net". that would be fine. > In this case, directlink.net is my ISP. They won't delegate PTR records so > that I can handle the DNS. This is pretty much normal -- ISPs have little > interest in doing DNS right for smaller customers like me. I had to fight > them to get a name that was even that close -- they started out with > something like dlci2184-3.dallas.directlink.net. directlink.net doesn't need to delegate you any ptr records. the only thing they need to do is to insert an srv record for dwillis3.directlink.net pointing to your fw/proxy. by the way, a good isp provides you a web page to control your domain names. > Furthermore, Directlink doesn't run a proxy, and if they did, I still > wouldn't trust them to run MY firewall proxy. they don't need to run a proxy. -- 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 daemon@optimus.ietf.org Mon Mar 4 03:20:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17019 for ; Mon, 4 Mar 2002 03:20:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA10999 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 03:20:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09227; Mon, 4 Mar 2002 02:42:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09196 for ; Mon, 4 Mar 2002 02:42:50 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16399 for ; Mon, 4 Mar 2002 02:42:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g247gLZ11432 for ; Mon, 4 Mar 2002 09:42:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 09:42:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 09:42:10 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) Date: Mon, 4 Mar 2002 09:42:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790A6@esebe019.NOE.Nokia.com> Thread-Topic: Expires in 2xx response to SUBSCRIBE (Events-04) Thread-Index: AcHASfYvR9RVz9BZTOenVGR/mYDINADBgFWg To: , X-OriginalArrivalTime: 04 Mar 2002 07:42:10.0789 (UTC) FILETIME=[17D79950:01C1C350] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA09197 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I'm reposting this since no reply was given. Regards, Hisham > -----Original Message----- > From: Khartabil Hisham (NMP/Helsinki) > Sent: Thursday, February 28, 2002 1:21 PM > To: adam@dynamicsoft.com; sip@ietf.org > Subject: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) > > > After a discussion with Robert Sparks here on the list about > what an Expires header actually means in a 200 response for a > REGISTER. It was concluded that it has no meaning. > > So, the following extract from section 4.1.6.1 in the events > draft is wrong: > > The "Expires" values present in SUBSCRIBE 200-class responses > behave in > the same way as they do in REGISTER responses: the server MAY shorten > the interval, but MUST NOT lengthen it. > > REGISTER responses now rely on expires-param in a Contact header. > > Below is an extract of the discussion Sparks and I had: > > >>Yes - the Expires header field in a 200 response to a > REGISTER request is > >>allowed. It also has no meaning with respect to the Contacts in > >>the response > >>since each provided Contact MUST contain an ;expires= parameter. > >>(Note to casual readers - this is a statement about the > _response_, not > >> the REGISTER request) > >> > >>So - help me understand your original question. Is it "why > don't you allow > >>the "use the expires parameter if present, otherwise use the > >>Expires header > >>value in REGISTER responses like you do in REGISTER requests?". > >> > > > > Yes, that was exactly what I asked. If its not so, what > does an Expires > > header in a 200 OK for a REGISTER mean? > > > As I note above, with the current text an Expire header field > has no meaning > if it appears in a 200 response to a REGISTER request. > > So? > > Regards, > Hisham Khartabil > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 04:15:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17735 for ; Mon, 4 Mar 2002 04:15:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14105 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 04:15:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13108; Mon, 4 Mar 2002 03:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13077 for ; Mon, 4 Mar 2002 03:57:23 -0500 (EST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17484 for ; Mon, 4 Mar 2002 03:57:17 -0500 (EST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g248qY232575; Mon, 4 Mar 2002 10:52:34 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 10:56:54 +0200 Message-ID: From: "Fuxbruner, Amihay" To: "'Jonathan Rosenberg'" , hisham.khartabil@nokia.com Cc: sip@ietf.org Subject: RE: [Sip] T4 Date: Mon, 4 Mar 2002 10:56:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Does it means that in case we send one request and receive one response there is no need to wait for timer K ? Amihay Fuxbruner System Engineering - Signaling R&D Comverse -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, February 27, 2002 10:15 AM To: hisham.khartabil@nokia.com Cc: sip@ietf.org Subject: Re: [Sip] T4 hisham.khartabil@nokia.com wrote: > > I included this in my comments in bis-07, but never got an answer. > > Why is T4 limited to 5 seconds for timer K in the case of non-INVITE > (section 17.1.2.2)? Sorry, I thought I had answered this somewhere. The idea is that you've sent a bunch of BYE requests, for example, and now you've got the final response. You want to hang around to catch any retransmits of that final response. How long to wait? The interesting thing about responses to BYE, is that they are not perioidcally sent; they are sent only in response to a request. So, the delay between sending a request, and getting a response, is equal to some value (say T4'), which represents the amount of time it takes for the request to get to the server, for the server to resend the response, and for the response to arrive at the client. Let T4 be the maximum value of T4' you might ever see, which I have set at around 5s. This should be more than sufficient. So, this means that if you've sent a retransmit of the request at time t, you would have received the response by t+T4 with very high probability, or you won't get one at all. So, if a UAC sends requests at times t1,t2,t3,t4, the responses would have arrived at t1+T4, t2+T4, t3+T4, t4+T4. The largest of those is t4+T4. Thus, we need to wait at least T4 seconds after the last request. Instead, we wait T4 after the first response, which is always more time (its simpler that way). Hope that helps. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 4 04:53:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18271 for ; Mon, 4 Mar 2002 04:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16326 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 04:53:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15413; Mon, 4 Mar 2002 04:32:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15380 for ; Mon, 4 Mar 2002 04:32:28 -0500 (EST) Received: from orgio.net ([211.224.96.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17923 for ; Mon, 4 Mar 2002 04:32:17 -0500 (EST) Message-Id: <200203040932.EAA17923@ietf.org> Reply-To: han0533@orgio.net From: 건강지킴이 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 4 Mar 2002 18:33:49 +0900 Subject: [Sip] ◆ 죄송합니다. 민간비방 자료[광고] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org @사전양해없이보내서정말로죄송합니다.@

@ 사전 양해없이 보내서 정말로 죄송합니다. @

===============================================================

◈◈◈ 홍화씨의 효능을 더욱 높인 유황홍화씨 ◈◈◈

 아직까지 유황홍화씨가 무엇인지 잘 모르시는 분들도 계시지요.

지금까지 각종 일반홍화씨로 효과을 재대로 못보신 분들은 꼭 방문해주세요.

유황오리가 몸에 좋다는 것은 다 아시지요.

바로 유황을 먹여서 그러한 것입니다.

유황홍화씨는 그 효능을 더욱 높이기 위해서 유황을 뿌려서 유황이 가진

좋은 보양성분을 홍화가 흡수하도록 한....

        

           0) 뼈가 부러져서 잘 븥지 않는 분

           1) 온 몸이 쑤시고 결리시는 분

           2) 어린이 성장 장애

           3) 뼈가 약한 분

           4) 몸이 피곤하고 무거운 분

           5) 대변 보기가 힘드신 분

           6) 온몸이 차고 저리신 분

           7) 출산 후 산후조리를 하시는 분

           8) 서서 일하기 때문에 발이 붓고 피곤하신 분

           9) 노약자 및 건강회복을 요하는 분

          10) 각종 성인병 예방하실 분

 연로하신 부모님 효도 선물로 그만 입니다.

◈ 홈페이지  http://www.hongwha.net/  이곳을 지금 바로 ◈

방문해주세요

==========================================================================

사전 양해없이 보내서 죄송합니다.
본 메일은 인터넷상에 올라 있는 메일주소를 보고 발췌하여 발송하였습니다.
본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.

원치 않으시면 삭제하시거나 '수신거부'를 클릭해서 보내주세요

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 07:46:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22267 for ; Mon, 4 Mar 2002 07:46:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25904 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 07:46:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24112; Mon, 4 Mar 2002 07:13:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24082 for ; Mon, 4 Mar 2002 07:13:30 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21192 for ; Mon, 4 Mar 2002 07:13:27 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g24CCKS21229; Mon, 4 Mar 2002 06:12:20 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g24CCJs20810; Mon, 4 Mar 2002 06:12:19 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g24CCJE13377; Mon, 4 Mar 2002 07:12:19 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 07:12:19 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03749F@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'jh@lohi.eng.song.fi'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Mon, 4 Mar 2002 07:12:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org First, you are extending the meaning of record-route in core SIP. Secondly, it does not fully solve the problem of 3GPP, as the registrar will need to include itself in the PATH, in the response sent to the mobile for subsequent requests. I dont think it is clean to tinker with record-route. /gf > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, March 04, 2002 1:00 AM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Path to Working Group Item > > > Dean Willis writes: > > > It seems that you are suggesting that 3G's implementation > of SIP should work > > completely differently from regular SIP? That seems like a > questionable idea > > to me. > > 3gpp is a closed community which will exactly define how their phone, > registrar, or proxy will work and will specify it in their standards. > so it would not be any hassle for them to say that a 3gpp registrar > stores the contact information of visiting phones as domain > names. this > was the only new thing that i proposed and it would be purely an > implementation issue not affecting ietf sip standards. > > but lets now get back to your new example, where (i think) > you have been > given a subnet of global ip addresses for your home or small business, > but your isp is not willing to add an srv record for the domain > *.dlci2184-3.dallas.directlink.net. that so if i have understood > correctly, your case is this: > > SIP UA --- LAN --- FW/Proxy --- Internet --- Registrar > > and that would like to do is to make incoming calls to your ua to be > routed via your fw/proxy. > > by the way, since you said that this is a real world example, > where did > you buy the FW/Proxy? i would like to buy one too, but haven't yet > found anything that would suit the budged of a home/small > business user. > > what you describe is a valid problem and luckily we already have a > header that solves it. that header is called record-route. when you > send your register message to your fw/proxy, that proxy, > knowing that it > needs to be on the path when someone calls you, adds a record-route > header to the register message and forwards it to your > registrar. your > registrar then inserts the record route along with the contact address > in its database. when someone calls you, the proxy of the registrar's > domain adds the corresponding route header to the invite > message and we > are done. > > the only thing we thus need to do to solve this valid problem > is to make > a small change to the text of the bis regarding record routing of > register messages. > > -- 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 daemon@optimus.ietf.org Mon Mar 4 07:53:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22432 for ; Mon, 4 Mar 2002 07:53:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26117 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 07:53:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24747; Mon, 4 Mar 2002 07:28:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24716 for ; Mon, 4 Mar 2002 07:28:41 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21715 for ; Mon, 4 Mar 2002 07:28:37 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hrZy-0006hN-00; Mon, 04 Mar 2002 14:28:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.26738.684307.277951@harjus.eng.song.fi> Date: Mon, 4 Mar 2002 14:28:34 +0200 To: "George Foti (LMC)" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C03749F@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C03749F@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > First, you are extending the meaning of record-route in core SIP. > Secondly, it does not fully solve the problem of 3GPP, as the registrar > will need to include itself in the PATH, in the response sent to the mobile > for subsequent requests. what i'm proposing is make record routing now to apply also to the register messages, which is much cleaner that inventing a new message for the same purpose. by record routing a register message, the network allows registering both the contact address and the route to it, which is consistent of the meaning of record route. your other "requirement", i.e., that the mobile should get back the route to be used for subsequent requests, i have already before dismissed as bogus, because it is grossly against the sip protocol architecture. in sip, register messages do not establish a dialogue and in sip anyone is able to make a call without first registering itself. -- 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 daemon@optimus.ietf.org Mon Mar 4 08:00:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22625 for ; Mon, 4 Mar 2002 08:00:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26697 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 08:00:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25519; Mon, 4 Mar 2002 07:36:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25493 for ; Mon, 4 Mar 2002 07:36:38 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22013 for ; Mon, 4 Mar 2002 07:36:34 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g24CaWh11080; Mon, 4 Mar 2002 06:36:32 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g24CaWm16449; Mon, 4 Mar 2002 06:36:32 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g24CaWE13746; Mon, 4 Mar 2002 07:36:32 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 07:37:00 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374A0@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'jh@lohi.eng.song.fi'" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Mon, 4 Mar 2002 07:36:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org inline > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Monday, March 04, 2002 7:29 AM > To: George Foti (LMC) > Cc: Dean Willis; sip@ietf.org > Subject: RE: [Sip] Path to Working Group Item > > > George Foti (LMC) writes: > > > First, you are extending the meaning of record-route in core SIP. > > Secondly, it does not fully solve the problem of 3GPP, as > the registrar > > will need to include itself in the PATH, in the response > sent to the mobile > > for subsequent requests. > > what i'm proposing is make record routing now to apply also to the > register messages, which is much cleaner that inventing a new message > for the same purpose. by record routing a register message, > the network > allows registering both the contact address and the route to it, which > is consistent of the meaning of record route. > > your other "requirement", i.e., that the mobile should get back the > route to be used for subsequent requests, i have already before > dismissed as bogus, because it is grossly against the sip protocol > architecture. in sip, register messages do not establish a > dialogue and It does not establish a dialogue. It establishes a PATH. If you dont want to bother to understand the 3GPP architecture, stop making *silly* comments about a requirement being bogus. I suggest that you read more before making *irresponsible* statements specially when you talk about saving bandwidth > in sip anyone is able to make a call without first registering itself. > > -- 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 daemon@optimus.ietf.org Mon Mar 4 08:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22747 for ; Mon, 4 Mar 2002 08:06:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27170 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 08:06:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25837; Mon, 4 Mar 2002 07:43:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25806 for ; Mon, 4 Mar 2002 07:43:51 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22227 for ; Mon, 4 Mar 2002 07:43:45 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16hrof-0006hl-00; Mon, 04 Mar 2002 14:43:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.27649.787333.237161@harjus.eng.song.fi> Date: Mon, 4 Mar 2002 14:43:45 +0200 To: "George Foti (LMC)" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C0374A0@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C0374A0@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > It does not establish a dialogue. It establishes a PATH. > If you dont want to bother to understand the 3GPP architecture, stop making > *silly* comments about a requirement being bogus. > I suggest that you read more before making *irresponsible* statements > specially when you talk about saving bandwidth george, calm down, this is just a game, not a personal affair. no matter what you call your thing, in sip there is no need to establish anything before a ua can start sending invite and other non-register messages. any "requirement" that doesn't accept that is bogus. -- 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 daemon@optimus.ietf.org Mon Mar 4 08:18:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23073 for ; Mon, 4 Mar 2002 08:18:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27617 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 08:18:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26776; Mon, 4 Mar 2002 08:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26745 for ; Mon, 4 Mar 2002 08:00:39 -0500 (EST) Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22641 for ; Mon, 4 Mar 2002 08:00:35 -0500 (EST) Received: from nt-mail.radvision.com ([212.143.185.30]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GSG001G79G6YE@mxout2.netvision.net.il> for sip@ietf.org; Mon, 04 Mar 2002 15:00:06 +0200 (IST) Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2650.21) id ; Mon, 04 Mar 2002 14:59:23 +0200 Content-return: allowed Date: Mon, 04 Mar 2002 14:59:22 +0200 From: Boris Perlov To: "'sip@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [Sip] SIP DNS usage issues (draft-ietf-sip-srv-06) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hello, I found following issues not clear in the SIP-SRV draft 06. Please advice what procedure should be applied. 1. In client transaction DNS usage, it is not clear if all records, returned by a NAPTR query, should be used in case of consequent procedure failure. NAPTR query output may include multiple records for the same domain. After choosing the best (order & preference) NAPTR record and in case of consequent procedure failure (e.g. sending message failure), should next NAPTR record be used? 2. In client transaction IP & port resolution procedure - paragraph 4.2, the draft-ietf-sip-srv-06 specifies that "...If no SRV records were found, the client performs an A or AAAA record lookup of the domain name.". How domain name will be determinate in case SRV lookup where applied on SRV host name, returned by previous NAPTR procedure? Will it be correct to use returned by NAPTR SRV name for the A/AAAA DNS query? 3. Although it can be guessed but it may be good to specify what port number should be used in case A/AAAA DNS query, applied as a result of SRV query failure, succeed. That because SRV query should be applied when port number was unspecified. Thanks, Boris Perlov RADVISION _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 08:29:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23567 for ; Mon, 4 Mar 2002 08:29:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28525 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 08:29:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27299; Mon, 4 Mar 2002 08:09:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27272 for ; Mon, 4 Mar 2002 08:09:42 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22820 for ; Mon, 4 Mar 2002 08:09:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g24D6mZc002865 for ; Mon, 4 Mar 2002 14:06:49 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g24D6mof029371 for ; Mon, 4 Mar 2002 15:06:48 +0200 (EET) Message-ID: <3C8371A6.7905637F@lmf.ericsson.se> Date: Mon, 04 Mar 2002 15:07:50 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] PRACK question: draft-ietf-sip-100rel-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A short clarification question on PRACK. Assume the following case UA_A sends an INVITE, with an SDP (offer 1). UA_B sends back a 18x provisional response, WITHOUT SDP. UA_A sends PRACK. My question is: is UA_A now allowed to include an SDP in the PRACK? It would be a new offer (offer 2), without an answer for the first offer (offer 1). No, this case is NOT described in chapter 5, but the generic description of PRACK says that it may always include an SDP, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 10:26:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28515 for ; Mon, 4 Mar 2002 10:26:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05247 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 10:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04295; Mon, 4 Mar 2002 10:06:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04266 for ; Mon, 4 Mar 2002 10:06:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27638 for ; Mon, 4 Mar 2002 10:06:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g24F6c6Y024658; Mon, 4 Mar 2002 10:06:39 -0500 (EST) Message-ID: <3C838D46.E0B34B94@dynamicsoft.com> Date: Mon, 04 Mar 2002 10:05:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] PRACK question: draft-ietf-sip-100rel-06 References: <3C8371A6.7905637F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > A short clarification question on PRACK. > > Assume the following case > > UA_A sends an INVITE, with an SDP (offer 1). > > UA_B sends back a 18x provisional response, WITHOUT SDP. > > UA_A sends PRACK. > > My question is: is UA_A now allowed to include an SDP in the PRACK? It > would be a new offer (offer 2), without an answer for the first offer > (offer 1). No. Please see lines 2116 to 2118 in -09 PDF. You cannot send a new offer until you've gotten an answer to your previous. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 4 10:26:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28549 for ; Mon, 4 Mar 2002 10:26:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05313 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 10:26:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03721; Mon, 4 Mar 2002 10:01:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03679 for ; Mon, 4 Mar 2002 10:01:02 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27283 for ; Mon, 4 Mar 2002 10:00:59 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g24F11h15930 for ; Mon, 4 Mar 2002 09:01:01 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g24F11d07256 for ; Mon, 4 Mar 2002 09:01:01 -0600 (CST) Received: from lmf.ericsson.se (rmt160162.am.ericsson.se [138.85.160.162]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA28436; Mon, 4 Mar 2002 09:00:57 -0600 (CST) Message-ID: <3C838C70.A3B55F8A@lmf.ericsson.se> Date: Mon, 04 Mar 2002 17:02:08 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] PRACK question: draft-ietf-sip-100rel-06 References: <3C8371A6.7905637F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A similar scenario to the one you have just described was discueed in the list not so long ago. No, the UAC cannot send a new offer until it has received the answer... the same way, if the UAC did not include an offer in the INVITE, it has to wait until the UAS provides one... that is, the UAC cannot send an initial offer in a PRACK. Regards, Gonzalo Christer Holmberg wrote: > > Hi, > > A short clarification question on PRACK. > > Assume the following case > > UA_A sends an INVITE, with an SDP (offer 1). > > UA_B sends back a 18x provisional response, WITHOUT SDP. > > UA_A sends PRACK. > > My question is: is UA_A now allowed to include an SDP in the PRACK? It > would be a new offer (offer 2), without an answer for the first offer > (offer 1). > > No, this case is NOT described in chapter 5, but the generic description > of PRACK says that it may always include an SDP, so... > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Mon Mar 4 11:59:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02938 for ; Mon, 4 Mar 2002 11:59:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11893 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 11:59:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09789; Mon, 4 Mar 2002 11:35:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09676 for ; Mon, 4 Mar 2002 11:35:21 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01313 for ; Mon, 4 Mar 2002 11:35:16 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g24GYFl19273; Mon, 4 Mar 2002 10:34:15 -0600 Message-ID: <008901c1c39a$69ad27a0$133fed0c@C1893415A> From: "Dean Willis" To: , References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A><15489.50086.993050.645336@harjus.eng.song.fi><003901c1c280$355c2c00$133fed0c@C1893415A><15489.54093.327411.43727@harjus.eng.song.fi><002101c1c2f7$6951e550$133fed0c@C1893415A><15490.37845.661770.900419@harjus.eng.song.fi><004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> <15491.3421.688850.744507@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Mon, 4 Mar 2002 10:34:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha said: > Dean Said: > > It seems that you are suggesting that 3G's implementation of SIP should work > > completely differently from regular SIP? That seems like a questionable idea > > to me. > > 3gpp is a closed community which will exactly define how their phone, > registrar, or proxy will work and will specify it in their standards. > so it would not be any hassle for them to say that a 3gpp registrar > stores the contact information of visiting phones as domain names. this > was the only new thing that i proposed and it would be purely an > implementation issue not affecting ietf sip standards. I'm really working very hard to try and keep this relationship as open and interoperable as possible. One of the things I've been repeatedly told by the ADs is that if a 3GPP phone is designed such that it can't interwork cleanly with "normal" internet systems, then we've failed horribly. On first glance, I think what you are proposing could be done in a fairly transparent manner, but I have the hunch there would be some real complexities involving many of the load-balancing and availability mechanisms that might be needed. I also suspect it would end up confusing a lot of people. > but lets now get back to your new example, where (i think) you have been > given a subnet of global ip addresses for your home or small business, > but your isp is not willing to add an srv record for the domain > *.dlci2184-3.dallas.directlink.net. that so if i have understood > correctly, your case is this: > > SIP UA --- LAN --- FW/Proxy --- Internet --- Registrar > > and that would like to do is to make incoming calls to your ua to be > routed via your fw/proxy. > > by the way, since you said that this is a real world example, where did > you buy the FW/Proxy? i would like to buy one too, but haven't yet > found anything that would suit the budged of a home/small business user. It's the advantage of working with clever developers. I think the commercial version with hardware sells for something like $100k . . . Actually, Billy Biggs had a working SIP ALG for LINUX available at one time, and I believe Intertex has a "consumer oriented" SIP firewall box in the $200 price range. > what you describe is a valid problem and luckily we already have a > header that solves it. that header is called record-route. when you > send your register message to your fw/proxy, that proxy, knowing that it > needs to be on the path when someone calls you, adds a record-route > header to the register message and forwards it to your registrar. your > registrar then inserts the record route along with the contact address > in its database. when someone calls you, the proxy of the registrar's > domain adds the corresponding route header to the invite message and we > are done. > > > the only thing we thus need to do to solve this valid problem is to make > a small change to the text of the bis regarding record routing of > register messages. That's exactly what the Path: header mechanism does. It defines a new header, Path, that works basically like Record-Route might if record-route worked on Register messages (which it doesn't right now). We debated using Record-Route as the header name instead of Path, and seemed to think that the behavior with REGISTER was just enough different from the behavior with INVITE that it justified a different header name. The major difference is that Path, as documented, provides asymmetric routing and record-route is by definition symmetric. So would you propose to call the header-for-use-with-REGISTER Record-Route instead of Path? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 4 12:27:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04715 for ; Mon, 4 Mar 2002 12:27:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15884 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 12:27:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11681; Mon, 4 Mar 2002 11:59:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11651 for ; Mon, 4 Mar 2002 11:59:08 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02854 for ; Mon, 4 Mar 2002 11:59:03 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g24Gw5l19417; Mon, 4 Mar 2002 10:58:05 -0600 Message-ID: <009101c1c39d$bdf2eae0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A><15489.50086.993050.645336@harjus.eng.song.fi><003901c1c280$355c2c00$133fed0c@C1893415A><15489.54093.327411.43727@harjus.eng.song.fi><002101c1c2f7$6951e550$133fed0c@C1893415A> <15491.5226.868652.473823@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Mon, 4 Mar 2002 10:58:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > In this test case, if the dynamicsoft.com proxy were to do a reverse lookup > > on 63.64.250.84, it would find that that this address resolves as > > "dwillis3.directlink.net". > > that would be fine. > > > In this case, directlink.net is my ISP. They won't delegate PTR records so > > that I can handle the DNS. This is pretty much normal -- ISPs have little > > interest in doing DNS right for smaller customers like me. I had to fight > > them to get a name that was even that close -- they started out with > > something like dlci2184-3.dallas.directlink.net. > > directlink.net doesn't need to delegate you any ptr records. the only > thing they need to do is to insert an srv record for > dwillis3.directlink.net pointing to your fw/proxy. by the way, a good > isp provides you a web page to control your domain names. Ah. Perhaps Finnish ISPs are more competent than American ones. I pay $110/month for this connection, and actually, I'm very glad to have even the service I get. I waited three months for installation. I don't believe the version of bind that Directlink was running even supported SRV records, much less nifty stuff like NAPTR.. As I said, it took several days of persuasion to get the original Directlink people not to give me hostnames like dlci-xxxx-y . . . Then the original Directlink was acquired by Allied-Riser, which ran it for about three months then bailed out of the ISP business giving me a 30-day notice to find a new ISP. The assets were acquired by Waymark, who (although they keep the service running pretty well) has expressed no interest to me in making any improvements. And if Waymark goes away, I have the choice of going to $300/month commercial service from Verizon, the local phone company (former GTE), or switching to an AT&T cable modem. And if you think either of these two phone-megaliths (Verizon or AT&T) has any interest in making my SIP connection work the way I want it to, you're sadly mistaken. AT&T would probably force me to disconnect service if they noticed me running a SIP server at all, just like they do for people who run their own SMTP servers. They also only support DHCP, which would require some sort of dynamic-DNS customization to work the way you're proposing. They would have to dynamically create the SRV binding based on sort sort of known-association between two address-requesting hosts using the DHCP identifier string. That's hard. I'm sure AT&T is considering selling me some sort of specialized-3GPP-like QoS connection service for SIP, but I bet they'll expect me to use their proxies and probably their hard phone too. Verizon's DNS provides no consumer SRV records and their PTR records all encode the IP address. No joke, the ptr record for 66.12.12.130 (where www.softarmor.com lives this week) is bdsl.66.12.12.130.gte.net. That's right, every host in their network has the same name, but they are all in different subdomains. We pay roughly $800/month for this service at the office for a 1/2 T1-equivalent DSL connection. The string "bdsl" appears to mean "business dsl", as in the American colloquialism "giving us the businesss". So in short, expecting flexibility from the US ISPs providing DNS service is not likely to be a path leading to success. Perhaps the rest of the world is more fortunate. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 4 13:31:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08214 for ; Mon, 4 Mar 2002 13:31:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20729 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 13:31:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18979; Mon, 4 Mar 2002 13:11:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18947 for ; Mon, 4 Mar 2002 13:11:53 -0500 (EST) Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07180 for ; Mon, 4 Mar 2002 13:11:50 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v32.5.) id 7.78.22f62ba8 (657); Mon, 4 Mar 2002 13:10:43 -0500 (EST) Message-ID: <78.22f62ba8.29b512a3@aol.com> Date: Mon, 4 Mar 2002 13:10:43 EST Subject: Re: [Sip] Comments on Resource Priority Header To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 3/1/02 8:32:10 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > Somebody (you?) argued that ignoring the value should not be the same as > having the lowest priority value. > We don't have a lot of choice. It has to state what will happen to a call attempt if the priority value is not understood. A statement that it is treated as the lowest known value is about all that could be done. I don't see the value in defining a "default" other than the lowest. > > > > Frankly, I don't see this as a problem in practice. Almost all of these > namespaces will be inherited from some existing scheme, so the > likelihood that somebody suddenly adds a value is pretty low. > I guess if the current version of "resource priority" prevents adding priority values, it would only mean that, if a network wanted to add a new value, there would need to be a revision to the RFC to tell IANA that it was allowed. You're right - not too significant of a problem. > Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 4 14:04:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11721 for ; Mon, 4 Mar 2002 14:04:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24234 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 14:04:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22426; Mon, 4 Mar 2002 13:49:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22397 for ; Mon, 4 Mar 2002 13:49:29 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10707 for ; Mon, 4 Mar 2002 13:49:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g24IkmT8003992; Mon, 4 Mar 2002 13:46:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 13:48:56 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300D8@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'George Foti (LMC)'" , "'sip@ietf.org'" Subject: RE: [Sip] Question on Events-04 draft Date: Mon, 4 Mar 2002 13:48:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: George Foti (LMC) [mailto:George.Foti@ericsson.ca] > > When would one in practice use probation as a reason code. > Is this a graceful server failure case? Yes, this was added for the maintainance case. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 4 16:03:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23101 for ; Mon, 4 Mar 2002 16:03:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01448 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 16:03:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29424; Mon, 4 Mar 2002 15:31:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29367 for ; Mon, 4 Mar 2002 15:31:09 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20337 for ; Mon, 4 Mar 2002 15:31:02 -0500 (EST) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g24KAJH11872; Tue, 5 Mar 2002 01:40:29 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B72.006FB421 ; Tue, 5 Mar 2002 01:50:06 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: sip@ietf.org, dean.willis@softarmor.com Message-ID: <65256B72.006FB368.00@sampark.hss.hns.com> Date: Tue, 5 Mar 2002 01:50:03 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Clarification relating to the Path header usage. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Jonathan, Recently you had posted to the mailing list suggesting that the Path header fulfills 2 requirements: One (which was under debate) regarding me knowing the path that outgoing requests I originate should take. This was regarding loose source-routing. The other one is mentioned below from your text: > Path fills two needs, and you have omitted the second > one. The second one is so that INCOMING calls to me, > can be routed from my home proxy through an intermediate > proxy that needs to be visited. I think this is well > within the scope of an extension to REGISTER, and I know > of no other alternative to solve it. This is needed for > any kind of visiting/roaming network where a local proxy > needs to be visited for incoming calls. My doubt is regarding this second usage. This works well when the home proxy knows that there is one and only one hop that is to be covered between the home proxy and me. In case there are more than one hops to be traversed, does each hop in the path need to remember the previous hop? Consider the scenario: UA1 --> P1 --> P2 --> registrar | | home_proxy <-- UA2 registrar remembers Path as , for reaching UA1. Now UA2 tries to reach UA1 via is home proxy. The query with the registrar returns that both P2 and P1 should be contacted (in that order). So far so good. Now, how does "home_proxy" convey the information that P2 should send the request to P1? It cannot add a Route header. Should home_proxy add the Path header to the request from UA2 and *somehow* make P1 understand this is the next hop? If so, how? Details for this are missing in the draft.... Or am I missing something here? Regards, Siddharth. -------------------- Siddharth Toshniwal @ Hughes Software Systems. http://www.hssworld.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 daemon@ns.ietf.org Mon Mar 4 16:08:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23354 for ; Mon, 4 Mar 2002 16:07:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01531 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 16:08:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29546; Mon, 4 Mar 2002 15:32:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29509 for ; Mon, 4 Mar 2002 15:32:11 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20474 for ; Mon, 4 Mar 2002 15:32:05 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g24KTQT8004957; Mon, 4 Mar 2002 15:29:27 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 15:31:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300DE@DYN-TX-EXCH-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Adam Roach , sip@ietf.org Subject: RE: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) Date: Mon, 4 Mar 2002 15:31:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The pedantic answer would be "I'm referring to the expires *values*, not the literal expires header." The truthful answer is that this is a minor oversight that I don't think warrants re-issuing the draft, as it is merely confusing, not incorrect (per the "pedantic answer," above). /a (What, you expected to make a pedantic comment and get a non- pedantic answer?) > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, March 04, 2002 1:42 AM > To: adam@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) > > > I'm reposting this since no reply was given. > > Regards, > Hisham > > > -----Original Message----- > > From: Khartabil Hisham (NMP/Helsinki) > > Sent: Thursday, February 28, 2002 1:21 PM > > To: adam@dynamicsoft.com; sip@ietf.org > > Subject: [Sip] Expires in 2xx response to SUBSCRIBE (Events-04) > > > > > > After a discussion with Robert Sparks here on the list about > > what an Expires header actually means in a 200 response for a > > REGISTER. It was concluded that it has no meaning. > > > > So, the following extract from section 4.1.6.1 in the events > > draft is wrong: > > > > The "Expires" values present in SUBSCRIBE 200-class responses > > behave in > > the same way as they do in REGISTER responses: the server > MAY shorten > > the interval, but MUST NOT lengthen it. > > > > REGISTER responses now rely on expires-param in a Contact header. > > > > Below is an extract of the discussion Sparks and I had: > > > > >>Yes - the Expires header field in a 200 response to a > > REGISTER request is > > >>allowed. It also has no meaning with respect to the Contacts in > > >>the response > > >>since each provided Contact MUST contain an ;expires= parameter. > > >>(Note to casual readers - this is a statement about the > > _response_, not > > >> the REGISTER request) > > >> > > >>So - help me understand your original question. Is it "why > > don't you allow > > >>the "use the expires parameter if present, otherwise use the > > >>Expires header > > >>value in REGISTER responses like you do in REGISTER requests?". > > >> > > > > > > Yes, that was exactly what I asked. If its not so, what > > does an Expires > > > header in a 200 OK for a REGISTER mean? > > > > > > As I note above, with the current text an Expire header field > > has no meaning > > if it appears in a 200 response to a REGISTER request. > > > > So? > > > > Regards, > > Hisham Khartabil > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 18:13:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29440 for ; Mon, 4 Mar 2002 18:13:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08183 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 18:13:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06443; Mon, 4 Mar 2002 17:41:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06398 for ; Mon, 4 Mar 2002 17:41:07 -0500 (EST) Received: from hotmail.com ([218.51.68.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28524 for ; Mon, 4 Mar 2002 17:41:02 -0500 (EST) Message-Id: <200203042241.RAA28524@ietf.org> Reply-To: hanbay7@hotmail.com From: HanBay To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 5 Mar 2002 07:38:10 +0900 Subject: [Sip] [광 고] 해외교포들의 한국식품 종합쇼핑몰 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org :+: 한베이 홍보메일 :+:
+ 클릭하시면 바로 저희 자료에서 귀하의 이메일 주소가 삭제됩니다   ☞ 수신거부
 
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 18:17:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29493 for ; Mon, 4 Mar 2002 18:17:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08249 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 18:17:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06883; Mon, 4 Mar 2002 17:55:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06852 for ; Mon, 4 Mar 2002 17:55:07 -0500 (EST) Received: from dns2.ulticomdal.com (IDENT:root@dns2.ulticomdal.com [204.130.158.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28892 for ; Mon, 4 Mar 2002 17:55:02 -0500 (EST) Received: from pcsun63 (pc-sun63.ulticomdal.com [204.130.158.238]) by dns2.ulticomdal.com (8.9.3/8.9.3) with SMTP id QAA30228 for ; Mon, 4 Mar 2002 16:55:01 -0600 From: "Hussam Jarada" To: Date: Mon, 4 Mar 2002 16:54:57 -0600 Message-ID: <002601c1c3cf$9bdad120$ee9e82cc@ulticomdal.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C1C39D.51406120" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200203042241.RAA28524@ietf.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Subject: [Sip] =?ks_c_5601-1987?B?UkU6IFtTaXBdIFuxpCCw7V0gx9i/3LGzxve16cDHIMfR?= =?ks_c_5601-1987?B?sbm9xMewIMG+x9W87sfOuPQ=?= Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0027_01C1C39D.51406120 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit Is there’s any way we stop this kind of emails in SIP mailing list !!! Hussam Jarada Sr. Software Eng. Ulticom Inc. Ph. 972-726-9345 Fax. 972-726-9396 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of HanBay Sent: Monday, March 04, 2002 4:38 PM To: sip@ietf.org Subject: [Sip] [±¤ °i] CØ¿U±³Æ÷μeAC CN±¹½AC° A¾CO¼iCI¸o + 클릭하시면 바로 저희 자료에서 귀하의 이메일 주소가 삭제됩니다 ☞ 수신거부 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_0027_01C1C39D.51406120 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable :+: =C7=D1=BA=A3=C0=CC =C8=AB=BA=B8=B8=DE=C0=CF :+:

Is= there=A1=AFs any way we stop this kind of emails in SIP mailing list = !!!

 

Hussam = Jarada

S= r. Software Eng.

U= lticom Inc.

P= h. 972-726-9345

F= ax. 972-726-9396

<= span class=3DEmailStyle17> 

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf = Of HanBay
Sent: Monday, March 04, = 2002 4:38 PM
To: sip@ietf.org
Subject: [Sip] = [=A1=BE=A2=B4 =A1=C6í] Ç=A8=AA=A2=AFÜ=A1=BE=A9=F8=A8=A1=A1=C0µéÀ= Ç ÇÑ=A1=BE=A9=F6=A8=F6ÄÇ=A1=C6 = Á=A8=FAÇÕ=A8=F9îÇÎ=A2=ACô

 

 

+ =C5=AC=B8=AF=C7=CF=BD=C3=B8=E9 =B9=D9=B7=CE =C0=FA=C8=F1 =C0=DA=B7=E1=BF=A1=BC=AD =B1=CD=C7=CF=C0=C7 = =C0=CC=B8=DE=C0=CF =C1=D6=BC=D2=B0=A1 = =BB=E8=C1=A6=B5=CB=B4=CF=B4=D9   =A2=D1 =BC=F6=BD=C5=B0=C5=BA=CE

 

 <= /p>

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_0027_01C1C39D.51406120-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 19:35:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01689 for ; Mon, 4 Mar 2002 19:35:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12958 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 19:35:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09956; Mon, 4 Mar 2002 18:56:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09925 for ; Mon, 4 Mar 2002 18:56:34 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00666 for ; Mon, 4 Mar 2002 18:56:29 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA25082; Mon, 4 Mar 2002 15:56:01 -0800 (PST) Message-Id: <4.1.20020304172245.016e82e0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Mar 2002 17:55:34 -0600 To: Rohan Mahy , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] re: Path as WG item In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1626783811==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1626783811==_.ALT Content-Type: text/plain; charset="us-ascii" How about: User1@example.com *registers* with whichever domain that UA is in locally with the full "User1@example.com" If User1 is in example.com's domain, nothing gets redirected, everybody's happy If User1's UA is in another domain, then this registration is to that non-local domain, which replies with a temporary "User1.example.com@foreign.uk" (or whatever non-local domain example you want) Upon temporary acceptance to that registration (acknowledgement) back to User1's UA (now knowing it's in a non-local domain) User1's UA transmits a Redirect Registration back to his/her home domain Registrar Server (which is now known to be elsewhere) with the roaming temp address of "User1.example.com@foreign.uk" for logically where that UA is now and wants to be reached at From here, either User1's domain Registrar Server sends User1's UA an ACK to convey this is OK (authenticating the UA with its local domain), or can ACK this temp Redirect to foreign.com's Registrar Server to have any suggested or required authentication with that domain directly between locally trusted hosts. Either way, User1's UA needs to have an acknowledgement that this mobility has been accepted by that UA's local domain (therefore trusting that all subsequent calls to User1@example.com will be correctly redirected and the sessions completed) This adds steps to the mobility process, but should: - keep User1's original address as the beginning of the temp address; - have User1's UA some level of trust future sessions should come through to this new domain; - keep a simple awareness of communications between the two domains through this addressing scheme; - keeps all new INVITES going to User1's original domain where it now knows (with an easy step) where to redirect that INVITE to - creates an almost 3-way handshake between both Registrar Servers and the roaming UA just a thought..... At 02:59 PM 3/2/2002 -0800, Rohan Mahy wrote: > >Juha, > >Assume: > >REGISTER sip:home.org SIP/2.0 >To: sip:user@home.org >From: sip:user@home.org > >Are you suggesting: > >1) Contact: > >2) Contact: with an additional registration to xyz.com >(if so, what credentials would I use to authenticate my request?) > >3) something else > >thanks, >-rohan > > > > > > Path fills two needs, and you have omitted the second one. The second > > one is so that INCOMING calls to me, can be routed from my home proxy > > through an intermediate proxy that needs to be visited. I think this is > > well within the scope of an extension to REGISTER, and I know of no > > other alternative to solve it. This is needed for any kind of > > visiting/roaming network where a local proxy needs to be visited for > > incoming calls. > > >no i have not omitted that one. i proposed that if i'm visiting in a >network xyz.com, then my home proxy can route incoming calls to the >proxy of xyz.com that in turn knows where to forward the message within >that network. > >-- 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 ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1626783811==_.ALT Content-Type: text/html; charset="us-ascii"
How about:

User1@example.com *registers* with whichever domain that UA is in locally with the full "User1@example.com"

If User1 is in example.com's domain, nothing gets redirected, everybody's happy

If User1's UA is in another domain, then this registration is to that non-local domain, which replies with a temporary "User1.example.com@foreign.uk" (or whatever non-local domain example you want)

Upon temporary acceptance to that registration (acknowledgement) back to User1's UA (now knowing it's in a non-local domain)

User1's UA transmits a Redirect Registration back to his/her home domain Registrar Server (which is now known to be elsewhere) with the roaming temp address of "User1.example.com@foreign.uk" for logically where that UA is now and wants to be reached at

From here, either User1's domain Registrar Server sends User1's UA an ACK to convey this is OK (authenticating the UA with its local domain), or can ACK this temp Redirect to foreign.com's Registrar Server to have any suggested or required authentication with that domain directly between locally trusted hosts.

Either way, User1's UA needs to have an acknowledgement that this mobility has been accepted by that UA's local domain (therefore trusting that all subsequent calls to User1@example.com will be correctly redirected and the sessions completed)

This adds steps to the mobility process, but should:
        - keep User1's original address as the beginning of the temp address;
        - have User1's UA some level of trust future sessions should come through to this new domain;
        - keep a simple awareness of communications between the two domains through this addressing scheme;
        - keeps all new INVITES going to User1's original domain where it now knows (with an easy step) where to redirect that INVITE to
        - creates an almost 3-way handshake between both Registrar Servers and the roaming UA

just a thought.....


At 02:59 PM 3/2/2002 -0800, Rohan Mahy wrote:
>
>Juha,
>
>Assume:
>
>REGISTER sip:home.org SIP/2.0
>To: sip:user@home.org
>From: sip:user@home.org
>
>Are you suggesting:
>
>1) Contact: <sip:user@1.2.3.4?Route=xyz.com;lr>
>
>2) Contact: <sip:user@xyz.com>  with an additional registration to xyz.com
>(if so, what credentials would I use to authenticate my request?)
>
>3) something else
>
>thanks,
>-rohan
>
>
>
><jdr>
> > Path fills two needs, and you have omitted the second one. The second
> > one is so that INCOMING calls to me, can be routed from my home proxy
> > through an intermediate proxy that needs to be visited. I think this is
> > well within the scope of an extension to REGISTER, and I know of no
> > other alternative to solve it. This is needed for any kind of
> > visiting/roaming network where a local proxy needs to be visited for
> > incoming calls.
></jdr>
>
>no i have not omitted that one.  i proposed that if i'm visiting in a
>network xyz.com, then my home proxy can route incoming calls to the
>proxy of xyz.com that in turn knows where to forward the message within
>that network.
>
>-- juha
>
>
>
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1626783811==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 19:38:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01882 for ; Mon, 4 Mar 2002 19:38:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13114 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 19:38:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10955; Mon, 4 Mar 2002 19:11:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10924 for ; Mon, 4 Mar 2002 19:11:19 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00962 for ; Mon, 4 Mar 2002 19:11:16 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA12168; Mon, 4 Mar 2002 16:10:45 -0800 (PST) Message-Id: <4.1.20020304180812.09b2fd28@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Mar 2002 18:10:19 -0600 To: "SIP SIP" , sip@ietf.org From: "James M. Polk" Subject: Re: [Sip] (no subject) In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1627668293==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1627668293==_.ALT Content-Type: text/plain; charset="us-ascii" Maybe if the initiation messages included the session keys and the capabilities exchange for which cipher and other such stuff important to that media stream..... At 05:21 PM 3/3/2002 +0000, SIP SIP wrote: >If the media streams tke a different way than the signalling messages in SIp >how can the security of the media stream be guaranteed. > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.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 > >reliable transports). >As far as I understand the only response retransmissions are for ACK in >INVITE transaction. >What is the meaning of "response retransmissions" for none-INVITE >transaction ? > >Thanks, > >Amihay Fuxbruner >System Engineering - Signaling R&D >Comverse > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > >e. But opted >> > > > to cry >> > > > > wolf. Your only alternative has been to >> > discount the requirements. >> > > > >> > > > that is not true. i have suggested that you use >> > three things instead of >> > > > the path header: >> > > > >> > > > - dhcp to locate the proxy of the visited >> > network >> > > > - dns with load balancing to figure out the >> > proxy of the home network >> > > > - loose source routing to get the requests to >> > the home network >> > > > >> > > > and i haven't heard of any *convincing* >> > arguments why that is not >> > > > enough. >> > > >> > >Path fills two needs, and you have omitted the >> > second one. The second >> > >one is so that INCOMING calls to me, can be routed >> > from my home proxy >> > >through an intermediate proxy that needs to be >> > visited. I think this is >> > >well within the scope of an extension to REGISTER, >> > and I know of no >> > >other alternative to solve it. This is needed for >> > any kind of >> > >visiting/roaming network where a local proxy needs >> > to be visited for >> > >incoming calls. >> > > >> > >I would prefer to let us agree to adopt path as a >> > work item, with the >> > >current draft as a starting point, and then we can >> > continue to debate >> > >handling of outgoing calls. >> > > >> > >-Jonathan R. >> > > >> > >-- >> > >Jonathan D. Rosenberg, Ph.D. 72 Eagle >> > Rock Avenue >> > >Chief Scientist First Floor >> > >dynamicsoft East >> > Hanover, NJ 07936 >> > >jdrosen@dynamicsoft.com FAX: (973) >> > 952-5050 >> > >http://www.jdrosen.net PH: (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 >> > >> > >> > >>_________________________________________________________________ >> > MSN Photos is the easiest way to share and print >> > your photos: >> > http://photos.msn.com/support/worldwide.aspx >> > >> > >> > _______________________________________________ >> > Sip mailing list >> > https://www1.ietf.org/mailman/listinfo/sip >> > This list is for NEW development of the core SIP >> > Protocol >> > Use sip-implementors@cs.columbia.edu for questions >> > on current sip >> > Use sipping@ietf.org for new developments on the >> > application of sip >> >> >>__________________________________________________ >>Do You Yahoo!? >>Yahoo! Sports - sign up for Fantasy Baseball >>http://sports.yahoo.com > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.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 ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1627668293==_.ALT Content-Type: text/html; charset="us-ascii"
Maybe if the initiation messages included the session keys and the capabilities exchange for which cipher and other such stuff important to that media stream.....

At 05:21 PM 3/3/2002 +0000, SIP SIP wrote:
>If the media streams tke a different way than the signalling messages in SIp
>how can the security of the media stream be guaranteed.
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>reliable transports).
>As far as I understand the only response retransmissions are for ACK in
>INVITE transaction.
>What is the meaning of "response retransmissions" for none-INVITE
>transaction ?
>
>Thanks,
>
>Amihay Fuxbruner
>System Engineering - Signaling R&D
>Comverse
>
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip
>
>e. But opted
>> > > > to cry
>> > > >  > wolf. Your only alternative has been to
>> > discount the requirements.
>> > > >
>> > > > that is not true.  i have suggested that you use
>> > three things instead of
>> > > > the path header:
>> > > >
>> > > > - dhcp to locate the proxy of the visited
>> > network
>> > > > - dns with load balancing to figure out the
>> > proxy of the home network
>> > > > - loose source routing to get the requests to
>> > the home network
>> > > >
>> > > > and i haven't heard of any *convincing*
>> > arguments why that is not
>> > > > enough.
>> > >
>> > >Path fills two needs, and you have omitted the
>> > second one. The second
>> > >one is so that INCOMING calls to me, can be routed
>> > from my home proxy
>> > >through an intermediate proxy that needs to be
>> > visited. I think this is
>> > >well within the scope of an extension to REGISTER,
>> > and I know of no
>> > >other alternative to solve it. This is needed for
>> > any kind of
>> > >visiting/roaming network where a local proxy needs
>> > to be visited for
>> > >incoming calls.
>> > >
>> > >I would prefer to let us agree to adopt path as a
>> > work item, with the
>> > >current draft as a starting point, and then we can
>> > continue to debate
>> > >handling of outgoing calls.
>> > >
>> > >-Jonathan R.
>> > >
>> > >--
>> > >Jonathan D. Rosenberg, Ph.D.            72 Eagle
>> > Rock Avenue
>> > >Chief Scientist                         First Floor
>> > >dynamicsoft                             East
>> > Hanover, NJ 07936
>> > >jdrosen@dynamicsoft.com                 FAX: (973)
>> > 952-5050
>> > >http://www.jdrosen.net                  PH:  (973)
>> > 952-5000
>> > >
>> > >_______________________________________________
>> > >Sip mailing list
>> > >This list is for NEW development of the core SIP
>> > Protocol
>> > >Use sip-implementors@cs.columbia.edu for questions
>> > on current sip
>> > >Use sipping@ietf.org for new developments on the
>> > application of sip
>> >
>> >
>> >
>>_________________________________________________________________
>> > MSN Photos is the easiest way to share and print
>> > your photos:
>> >
>> >
>> > _______________________________________________
>> > Sip mailing list
>> > This list is for NEW development of the core SIP
>> > Protocol
>> > Use sip-implementors@cs.columbia.edu for questions
>> > on current sip
>> > Use sipping@ietf.org for new developments on the
>> > application of sip
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Yahoo! Sports - sign up for Fantasy Baseball
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1627668293==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 20:49:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03612 for ; Mon, 4 Mar 2002 20:49:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17090 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 20:49:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15876; Mon, 4 Mar 2002 20:23:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15849 for ; Mon, 4 Mar 2002 20:23:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03037 for ; Mon, 4 Mar 2002 20:23:01 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA08641; Mon, 4 Mar 2002 20:23:03 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g251N2NB023412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2002 20:23:02 -0500 (EST) Message-ID: <3C841DE8.EF774923@cs.columbia.edu> Date: Mon, 04 Mar 2002 20:22:48 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] Comments on Resource Priority Header References: <78.22f62ba8.29b512a3@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > We don't have a lot of choice. It has to state what will happen to a call > attempt if the priority value is not understood. A statement that it is > treated as the lowest known value is about all that could be done. I don't > see the value in defining a "default" other than the lowest. There are two choices: (1) If there's an unknown value, simply ignore the Resource-Priority header. (Any unknown namespace will have to cause the RP header to be ignored.) (2) Treat unknown values as the lowest priority. The two are the same if and only if "no RP header = well-defined RP value". I tend to think that that's a good general choice. I intentionally say "well-defined", since it may not be the lowest value. One could imagine a system where you can define a priority lower than a normal, unadorned call. As a contrived example, imagine a gas meter reader call, like the one my house gets around 10 pm each night, that would label itself as "left-over". (As I mentioned, there is something like that for IP QoS called scavenger service, or worse-than-best-effort, which scrounges up the bandwidth crumbs left over by BE traffic. Used for huge file transfers in Internet2.) From what I can tell, no such systems exist today, so this may be academic. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 4 20:59:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04017 for ; Mon, 4 Mar 2002 20:59:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17622 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 20:59:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16642; Mon, 4 Mar 2002 20:34:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16610 for ; Mon, 4 Mar 2002 20:34:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03370 for ; Mon, 4 Mar 2002 20:34:00 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251YG6Y025522; Mon, 4 Mar 2002 20:34:17 -0500 (EST) Message-ID: <3C842061.DE6F1E76@dynamicsoft.com> Date: Mon, 04 Mar 2002 20:33:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: hisham.khartabil@nokia.com, sip@ietf.org Subject: Re: [Sip] T4 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fuxbruner, Amihay" wrote: > > Does it means that in case we send one request and receive one response > there is no need to wait for timer K ? I would still recommend doing so. The Internet has been known to actually duplicate packets.. it doesn't happen often, but it does happen. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 4 23:14:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08438 for ; Mon, 4 Mar 2002 23:14:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA24286 for sip-archive@odin.ietf.org; Mon, 4 Mar 2002 23:14:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21999; Mon, 4 Mar 2002 22:37:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21970 for ; Mon, 4 Mar 2002 22:37:24 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07450 for ; Mon, 4 Mar 2002 22:37:19 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id TAA15888; Mon, 4 Mar 2002 19:36:15 -0800 (PST) Message-Id: <4.1.20020304213044.015e2680@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 04 Mar 2002 21:35:49 -0600 To: Henning Schulzrinne , Mpierce1@aol.com From: "James M. Polk" Subject: Re: [Sip] Comments on Resource Priority Header Cc: sip@ietf.org In-Reply-To: <3C841DE8.EF774923@cs.columbia.edu> References: <78.22f62ba8.29b512a3@aol.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1639998623==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1639998623==_.ALT Content-Type: text/plain; charset="us-ascii" At 08:22 PM 3/4/2002 -0500, Henning Schulzrinne wrote: >> We don't have a lot of choice. It has to state what will happen to a call >> attempt if the priority value is not understood. A statement that it is >> treated as the lowest known value is about all that could be done. I don't >> see the value in defining a "default" other than the lowest. > >There are two choices: > >(1) If there's an unknown value, simply ignore the Resource-Priority >header. (Any unknown namespace will have to cause the RP header to be >ignored.) > >(2) Treat unknown values as the lowest priority. > >The two are the same if and only if "no RP header = well-defined RP >value". I tend to think that that's a good general choice. I >intentionally say "well-defined", since it may not be the lowest value. I believe #2 above is more appropriate as it gives to local policy within a domain, and prevents the case where the RP header might be required or the packet(s) *do* get dropped for not complying with some local rule stating something like "every session packet must have RP included, if it doesn't, it wasn't authorized in the first place -- action: delete it" ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1639998623==_.ALT Content-Type: text/html; charset="us-ascii"
At 08:22 PM 3/4/2002 -0500, Henning Schulzrinne wrote:
>> We don't have a lot of choice. It has to state what will happen to a call
>> attempt if the priority value is not understood. A statement that it is
>> treated as the lowest known value is about all that could be done. I don't
>> see the value in defining a "default" other than the lowest.
>
>There are two choices:
>
>(1) If there's an unknown value, simply ignore the Resource-Priority
>header. (Any unknown namespace will have to cause the RP header to be
>ignored.)
>
>(2) Treat unknown values as the lowest priority.
>
>The two are the same if and only if "no RP header = well-defined RP
>value". I tend to think that that's a good general choice. I
>intentionally say "well-defined", since it may not be the lowest value.

I believe #2 above is more appropriate as it gives to local policy within a domain, and prevents the case where the RP header might be required or the packet(s) *do* get dropped for not complying with some local rule stating something like "every session packet must have RP included, if it doesn't, it wasn't authorized in the first place -- action: delete it"


*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1639998623==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 02:51:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20394 for ; Tue, 5 Mar 2002 02:51:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14945 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 02:51:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13410; Tue, 5 Mar 2002 02:29:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13379 for ; Tue, 5 Mar 2002 02:29:09 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19785 for ; Tue, 5 Mar 2002 02:29:06 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g257T4B11610; Tue, 5 Mar 2002 08:29:04 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g257T3of025546; Tue, 5 Mar 2002 09:29:03 +0200 (EET) Message-ID: <3C8473FF.B50CEE6E@lmf.ericsson.se> Date: Tue, 05 Mar 2002 09:30:07 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: Jonathan Rosenberg , gonzalo.camarillo@lmf.ericsson.se Subject: Re: [Sip] PRACK question: draft-ietf-sip-100rel-06 References: <3C8371A6.7905637F@lmf.ericsson.se> <3C838D46.E0B34B94@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Thanks for your answers! I know that we can't have two "active" offers. My point was that if it should be mentioned also in chapter 5 of the 100rel draft, but I guess it's not necessary. Another question: UA_A sends an INVITE, with SDP (offer 1). UA_B sends back the first 18x provisional response, WITH SDP (answer 1). UA_A sends the first PRACK, WITHOUT SDP. UA_B sends back the second 18x provisional response, WITHOUT SDP. UA_A sends the second PRACK, WITH SDP (offer 2). Now, at the same time as UA_A sends the second PRACK, UA_B sends a 200 final response for the INVITE (it does NOT have to wait for the second PRACK since the second 18x provisional response did NOT contain SDP). So, in this case there would be a race condition, since UA_B sends the final response BEFORE it receives the second PRACK (with offer 2). So, are we allowed to include an SDP (offer or answer) in the PRACK ONLY if the 18x provisional response being PRACKed contained an SDP? If not, how do we solve the race condition? Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > Christer Holmberg wrote: > > > > Hi, > > > > A short clarification question on PRACK. > > > > Assume the following case > > > > UA_A sends an INVITE, with an SDP (offer 1). > > > > UA_B sends back a 18x provisional response, WITHOUT SDP. > > > > UA_A sends PRACK. > > > > My question is: is UA_A now allowed to include an SDP in the PRACK? It > > would be a new offer (offer 2), without an answer for the first offer > > (offer 1). > > No. > > Please see lines 2116 to 2118 in -09 PDF. You cannot send a new offer > until you've gotten an answer to your previous. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Tue Mar 5 04:22:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21645 for ; Tue, 5 Mar 2002 04:22:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19771 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 04:22:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17892; Tue, 5 Mar 2002 03:49:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17863 for ; Tue, 5 Mar 2002 03:49:40 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21202 for ; Tue, 5 Mar 2002 03:49:36 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iAdd-0006x8-00; Tue, 05 Mar 2002 10:49:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.34464.981571.881300@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 10:49:36 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <008901c1c39a$69ad27a0$133fed0c@C1893415A> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> <002101c1c2f7$6951e550$133fed0c@C1893415A> <15490.37845.661770.900419@harjus.eng.song.fi> <004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> <15491.3421.688850.744507@harjus.eng.song.fi> <008901c1c39a$69ad27a0$133fed0c@C1893415A> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > I'm really working very hard to try and keep this relationship as open and > interoperable as possible. One of the things I've been repeatedly told by > the ADs is that if a 3GPP phone is designed such that it can't interwork > cleanly with "normal" internet systems, then we've failed horribly. i haven't proposed anything that would make a 3gpp phone from interworking cleanly with sip phones on the internet. it is up to the 3gpp folks if they will allow such interworking to take place smoothly. based on the comments on this list, they seem work hard to limit the interworking freedom of a 3gpp phone user in order to be able to collect from him or her as much money as possible. > So would you propose to call the header-for-use-with-REGISTER Record-Route > instead of Path? no. as i said, there is no need to invent a new header name. we can simply define the semantics of record-route for register messages. behavior of proxies would be exactly the same as for record routing other messages. you simply add a new configuration variable "recordRouteRegisterMessages" to which the operator of the proxy can assign a true or false value. the semantics at the registrar were already discussed yesterday: the registrar would add the recorded route along with the contact address in to its database. when the proxy of the registrar then receives a request bound for a local user, it would forward the request towards the contact address and add the recorded route to the route header of the request. the only reason why we would need to invent a new header name would be if using record routing of register request would not be backwards compatible with rfc 2543, i.e., if an old proxy that gets a register request that includes record-route, would break the request. i don't think that that would happen, because record-route has always been an optional header in register request. this solution would be fully compatible with sip protocol architecture, where a register request serves the purpose of others being able to reach me and where i have no need to send a register request as a prerequisite of me reaching others. -- 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 daemon@optimus.ietf.org Tue Mar 5 07:30:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26072 for ; Tue, 5 Mar 2002 07:30:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29680 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 07:30:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28844; Tue, 5 Mar 2002 07:06:11 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by optimus.ietf.org (8.9.1a/8.9.1) with SMTP id HAA28739 for ; Tue, 5 Mar 2002 07:06:04 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Tue, 5 Mar 2002 13:16:51 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <3C84C543.4307.6758FD@localhost> Priority: normal In-reply-to: <3C838D46.E0B34B94@dynamicsoft.com> X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Subject: [Sip] Offer/answer model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, I have a little doubt regarding the offer/answer model for session description used in SIP: if the offer is present in an INVITE message, then confirmation of receipt of the answer can be conveyed in the ACK. but what happens when the INVITE is blank? therefore being possible the offer to be sent back in the 200 OK, and the answer in the ACK. if the something goes wrong the answerer may think the offerer received the answer and initiate the session, while the offerer is still awaiting for the answer. It'd recommendable that after sending the ACK, the answerer send an UPDATE with its previous answer as offer and the other party confirmed the session description. comments? thanks, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 08:18:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28102 for ; Tue, 5 Mar 2002 08:18:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02395 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 08:18:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00828; Tue, 5 Mar 2002 07:54:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00801 for ; Tue, 5 Mar 2002 07:54:45 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26849 for ; Tue, 5 Mar 2002 07:54:43 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA16110; Tue, 5 Mar 2002 07:54:13 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA24831; Tue, 5 Mar 2002 07:54:13 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 07:54:12 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CBAC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Hussam Jarada'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Date: Tue, 5 Mar 2002 07:54:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C444.D8C0F8B0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C444.D8C0F8B0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable The list is open post; anyone, even non-subscribers are allowed to = post. The good part is that you can reply to a message in your area of = expertise even if you don't subscribe, and you can reply to a message from an account = that is not the one your subscription is from. =20 The downside is that some Spam gets through. There is a Spam filter = that stops a lot of it, but not all. Generally, the ADs prefer open posting even = at the cost of some Spam. If the Spam gets very heavy, we can get permission to go closed posting where the moderator (me) has to approve = non-subscriber posts. I don't think we have gotten to this level of Spam yet. =20 Brian -----Original Message----- From: Hussam Jarada [mailto:hussam.jarada@ulticomdal.com] Sent: Monday, March 04, 2002 5:55 PM To: sip@ietf.org Subject: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Is there=A1=AFs any way we stop this kind of emails in SIP mailing list = !!! =20 Hussam Jarada Sr. Software Eng. Ulticom Inc. Ph. 972-726-9345 Fax. 972-726-9396 =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of HanBay Sent: Monday, March 04, 2002 4:38 PM To: sip@ietf.org Subject: [Sip] [=A1=BE=A2=B4 =A1=C6i] = C=A8=AA=A2=AFU=A1=BE=A9=F8=A8=A1=A1=C0eAC CN=A1=BE=A9=F6=A8=F6AC=A1=C6 = A=A8=FACO=A8=F9iCI=A2=ACo =20 ------_=_NextPart_001_01C1C444.D8C0F8B0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable :+: =C7=D1=BA=A3=C0=CC =C8=AB=BA=B8=B8=DE=C0=CF :+:
The list is=20 open post; anyone, even non-subscribers are allowed to = post.
The good part=20 is that you can reply to a message in your area of expertise=20 even
if you don't=20 subscribe, and you can reply to a message from an account=20 that
is not the=20 one your subscription is from.
 
The downside=20 is that some Spam gets through.  There is a Spam filter that=20 stops
a lot of it,=20 but not all.  Generally, the ADs prefer open posting even at=20 the
cost of some=20 Spam.  If the Spam gets very heavy, we can get=20 permission
to go closed=20 posting where the moderator (me) has to approve=20 non-subscriber
posts. =20 I don't think we have gotten to this level of Spam = yet.
 
Brian
-----Original Message-----
From: Hussam Jarada=20 [mailto:hussam.jarada@ulticomdal.com]
Sent: Monday, March = 04, 2002=20 5:55 PM
To: sip@ietf.org
Subject: [Sip] RE: [Sip] = [? ?]=20 ?????? ???? ?????

Is=20 there=A1=AFs any way we stop this kind of emails in SIP mailing list=20 !!!

 

=

Hussam=20 Jarada

Sr.=20 Software Eng.

Ulticom=20 Inc.

Ph.=20 972-726-9345

Fax.=20 972-726-9396

=  

=

-----Original=20 Message-----
From: = sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of = HanBay
Sent: Monday, March 04, 2002 = 4:38=20 PM
To:=20 sip@ietf.org
Subject: [Sip]=20 [=A1=BE=A2=B4 =A1=C6í] = Ç=A8=AA=A2=AFÜ=A1=BE=A9=F8=A8=A1=A1=C0µéÀ= ;Ç ÇÑ=A1=BE=A9=F6=A8=F6ÄÇ=A1=C6 = Á=A8=FAÇÕ=A8=F9îÇÎ=A2=ACô<= /SPAN>

 

------_=_NextPart_001_01C1C444.D8C0F8B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 09:01:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00102 for ; Tue, 5 Mar 2002 09:01:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05459 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 09:01:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03650; Tue, 5 Mar 2002 08:37:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03616 for ; Tue, 5 Mar 2002 08:37:21 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28748 for ; Tue, 5 Mar 2002 08:37:20 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id AA1091270260; Tue, 05 Mar 2002 08:37:20 -0500 Message-ID: <00a301c1c44a$a089e460$2300000a@acmepacket.com> From: "Bob Penfield" To: , References: <3C84C543.4307.6758FD@localhost> Subject: Re: [Sip] Offer/answer model Date: Tue, 5 Mar 2002 08:35:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Salva Rey Calatayud" > > Hi, > > I have a little doubt regarding the offer/answer model for session > description used in SIP: > > if the offer is present in an INVITE message, then confirmation > of receipt of the answer can be conveyed in the ACK. > > but what happens when the INVITE is blank? therefore being > possible the offer to be sent back in the 200 OK, and the answer in > the ACK. if the something goes wrong the answerer may think the > offerer received the answer and initiate the session, while the > offerer is still awaiting for the answer. The answerer (the UAC in this case) does know that the offerer (the UAS) got the answer because the UAS will retransmit the 200-OK until it receives the ACK from the UAC. The requirement is that all answers and offers be in reliable messages, and that is the case here. > > It'd recommendable that after sending the ACK, the answerer > send an UPDATE with its previous answer as offer and the other > party confirmed the session description. > > comments? > > thanks, > Salva > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 09:20:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01026 for ; Tue, 5 Mar 2002 09:20:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06404 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 09:20:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04727; Tue, 5 Mar 2002 08:57:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04698 for ; Tue, 5 Mar 2002 08:57:55 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29780 for ; Tue, 5 Mar 2002 08:57:53 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g25DulM19260; Tue, 5 Mar 2002 13:56:47 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 13:57:18 -0000 Message-ID: From: "Mark Watson" To: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 13:57:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C44D.A62F05F0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C44D.A62F05F0 Content-Type: text/plain; charset="iso-8859-1" I would support this becoming a WG item. Juha seemed to be suggesting that Record-Route could be introduced to Register instead, but the semantics do seem slightly different to me (I thought Record-Route established a route for the duration of the dialog, but Registers don't set up a dialog). Plus the symmetry difference. So, I'd prefer to see the Path proposal go forwards. Regards...Mark > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 01 March 2002 23:08 > To: 'sip@ietf.org' > Subject: [Sip] Path to Working Group Item > > > There has been considerable discussion on the PATH header on the list > indicating more than significant interest to consider it a working > group item. Are there any objections? > > Brian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1C44D.A62F05F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Path to Working Group Item

I would support this becoming a WG item.

Juha seemed to be suggesting that Record-Route could = be introduced to Register instead, but the semantics do seem slightly = different to me (I thought Record-Route established a route for the = duration of the dialog, but Registers don't set up a dialog). Plus the = symmetry difference.

So, I'd prefer to see the Path proposal go = forwards.

Regards...Mark

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 01 March 2002 23:08
> To: 'sip@ietf.org'
> Subject: [Sip] Path to Working Group = Item
>
>
> There has been considerable discussion on the = PATH header on the list
> indicating more than significant interest to = consider it a working
> group item.  Are there any = objections?
>
> Brian
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1C44D.A62F05F0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 09:25:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01209 for ; Tue, 5 Mar 2002 09:25:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06647 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 09:25:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04798; Tue, 5 Mar 2002 08:58:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04768 for ; Tue, 5 Mar 2002 08:58:24 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29807 for ; Tue, 5 Mar 2002 08:58:22 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g25DuiM19246; Tue, 5 Mar 2002 13:56:44 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 13:57:16 -0000 Message-ID: From: "Mark Watson" To: jh@lohi.eng.song.fi, Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 13:57:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C44D.A593FE70" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C44D.A593FE70 Content-Type: text/plain > i haven't proposed anything that would make a 3gpp phone from > interworking cleanly with sip phones on the internet. it is up to the > 3gpp folks if they will allow such interworking to take place > smoothly. > based on the comments on this list, they seem work hard to limit the > interworking freedom of a 3gpp phone user in order to be able > to collect > from him or her as much money as possible. > Minor point, but limiting the destinations to which users can make calls *reduces* revenue, because users can make fewer calls and the service takeup will be depressed due to the perceived deficiency. It is in everyone's interest that interworking between SIP devices in 3GPP networks and in other networks (eg. the Internet) is as easy as possible (yours too, Juha, believe it or not). ...Mark ------_=_NextPart_001_01C1C44D.A593FE70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Path to Working Group Item

> i haven't proposed anything that would make a = 3gpp phone from
> interworking cleanly with sip phones on the = internet.  it is up to the
> 3gpp folks if they will allow such interworking = to take place
> smoothly.
> based on the comments on this list, they seem = work hard to limit the
> interworking freedom of a 3gpp phone user in = order to be able
> to collect
> from him or her as much money as = possible.
>

Minor point, but limiting the destinations to which = users can make calls *reduces* revenue, because users can make fewer = calls and the service takeup will be depressed due to the perceived = deficiency.

It is in everyone's interest that interworking = between SIP devices in 3GPP networks and in other networks (eg. the = Internet) is as easy as possible (yours too, Juha, believe it or = not).

...Mark

------_=_NextPart_001_01C1C44D.A593FE70-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 09:42:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02004 for ; Tue, 5 Mar 2002 09:42:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07770 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 09:42:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06247; Tue, 5 Mar 2002 09:16:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06216 for ; Tue, 5 Mar 2002 09:16:49 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00809 for ; Tue, 5 Mar 2002 09:16:47 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g25EGnh18785 for ; Tue, 5 Mar 2002 08:16:49 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g25EGnd02466 for ; Tue, 5 Mar 2002 08:16:49 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g25EGmE08365 for ; Tue, 5 Mar 2002 09:16:48 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 09:17:18 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374BA@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Tue, 5 Mar 2002 09:16:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Questions/Comments on privacy-04 draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have some questions/comments related to the subject draft: * Section 4 says "The first extension is a new general header, Remote-Party-ID, which identifies a party and is added by the trusted network entities" An untrusted UAC can insert one which needs to be verified by a trusted network entity. So the above statment seems to be incorrect? * Section 5 says "If the proxy wants to ensure that the calling party can be identified, the proxy MUST authenticate the calling party (by means outside the scope of this document) and insert a calling party......" Isnt the above statment true only if the UAC did not insert one, or if it inserted one that could not be properly verified. Section 7.5 describing proxy behavior suggests that. Furthermore, in that same section (7.5), it says that the proxy SHOULD include as opposed to MUST in section 5 (I guess to account for the case when the UAC inserts one that is verified and the proxy sets the screen to YES) Both sections should be consistent * In section 7.1 Untrusted UAC behavior - There is no mention that an untrusted UAC can include a Remote-Party-ID header, even though the protocol operation description section does allow for that. * In section 7.2 Trusted UAC behavior, it lists 2 different options, why isnt it possible that if option 1 is followed and a 420 response is received, that the UAC can default to option 2, i.e perform the necessary actions to support requested privacy and resubmit the request to the proxy. * Sections 7.3 & 7.4 do not fully describe how the UAS should deal with an incoming Request containing multiple Remote-Party-IDs. The same comment applies to the sections on UAC, when it comes to responses including multiple Remote-Party-IDs. * Section 7.5 describing proxy behavior says that a proxy many add one or more Remote-Party-ID headers. What would be the reason more than one may be included, any examples? Thx/gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 09:42:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02057 for ; Tue, 5 Mar 2002 09:42:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07820 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 09:42:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06110; Tue, 5 Mar 2002 09:14:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06083 for ; Tue, 5 Mar 2002 09:14:20 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00733 for ; Tue, 5 Mar 2002 09:14:18 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iFhl-00073b-00; Tue, 05 Mar 2002 16:14:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.53941.771033.602025@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 16:14:13 +0200 To: "Mark Watson" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Minor point, but limiting the destinations to which users can make calls > *reduces* revenue, because users can make fewer calls and the service takeup > will be depressed due to the perceived deficiency. mark, by limiting freedom i didn't mean limiting the number of end points that can be reached, but limiting the way how they can be reached. when i make a call from a 3gpp phone, i should be able to choose whether i want to route the invite to my home proxy or skip my home proxy and just use the services of the visited network if the visited network can give me a better deal that way. also, i should be able to equally choose to use call routing and gatewaying services of a third party that is not a mobile network operator at all and still get the same qos service over the wireless access link as i get when i use the services of the mobile network operator. with this background you should understand why i don't at all like the idea of breaking the sip protocol architecture and making registration a prerequisite for making calls and thus giving the mobile network operators yet another brick for their wall. -- 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 daemon@optimus.ietf.org Tue Mar 5 10:29:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04544 for ; Tue, 5 Mar 2002 10:29:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10275 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 10:29:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08177; Tue, 5 Mar 2002 09:54:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08146 for ; Tue, 5 Mar 2002 09:54:01 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02796 for ; Tue, 5 Mar 2002 09:53:58 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iGKD-00074v-00; Tue, 05 Mar 2002 16:53:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15492.56325.337875.744049@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 16:53:57 +0200 To: "Mark Watson" Cc: "Rosen, Brian" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > So, I'd prefer to see the Path proposal go forwards. the path proposal includes much more than fulfilling the valid requirement, i.e., learning the path to the registered user. if you want to call the header path instead of record-route, that is not a big deal to me, but those parts of the path proposal that break the sip protocol architecture are. in sip, register request accomplishes one and only one thing: lets others to learn that i'm available for calls and how their calls can reach me. the path proposal on the table is changing that in a fundamental way by establishing to the registering party a service route that it should be using when it makes calls. that part of the proposal breaks the sip protocol architecture and is thus unacceptable. -- 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 daemon@optimus.ietf.org Tue Mar 5 10:33:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04723 for ; Tue, 5 Mar 2002 10:33:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11049 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 10:33:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09035; Tue, 5 Mar 2002 10:04:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09006 for ; Tue, 5 Mar 2002 10:04:06 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03327 for ; Tue, 5 Mar 2002 10:04:04 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g25F3ad25992; Tue, 5 Mar 2002 07:03:36 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA09813; Tue, 5 Mar 2002 07:03:35 -0800 (PST) Message-ID: <3C84DE37.C4AFE85F@cisco.com> Date: Tue, 05 Mar 2002 10:03:20 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "George Foti (LMC)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BA@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "George Foti (LMC)" wrote: > I have some questions/comments related to the subject draft: > > * Section 4 says "The first extension is a new general header, > Remote-Party-ID, which identifies a party and is added by the trusted > network entities" > > An untrusted UAC can insert one which needs to be verified by a trusted > network entity. So the above statment seems to be incorrect? The Remote-Party-Id header extension is not intended to be included by untrusted user agents. Only trusted entities are supposed to add them, and that is what the draft describes. > > > * Section 5 says "If the proxy wants to ensure that the calling party > can be identified, the proxy MUST authenticate the calling party (by means > outside the scope of this document) and insert a calling party......" > > Isnt the above statment true only if the UAC did not insert one, No, and this is a very important point. The Remote-Party-Id is neither to be inserted by the untrusted UA, nor is it supposed to be used by an untrusted UA as a means of authentication - the draft is quite clear about this (see e.g. the applicability statement) > or if it > inserted one that could not be properly verified. Section 7.5 describing > proxy behavior suggests that. 7.5 defines general proxy behavior and hence needs to deal with the presence or absence of Remote-Party-Id. > > Furthermore, in that same section (7.5), it says that the proxy SHOULD > include as opposed to MUST in section 5 (I guess to account for the case > when the UAC inserts one that is verified and the proxy sets the screen to > YES) > Both sections should be consistent Section 5 says that "If the proxy wants to ensure, that the calling party can be identified by the called party, the proxy MUST..." (note the "if"). Section 7.5 gets into more detail and says that the proxy SHOULD ensure the calling party can be identified by including a Remote-Party-Id (if it knows the identity). I don't see any inconsistency here. > > > * In section 7.1 Untrusted UAC behavior - There is no mention that an > untrusted UAC can include a Remote-Party-ID header, and rightfully so. > even though the protocol > operation description section does allow for that. > No it does not, however are rules for dealing with the case where it happened anyway. > > * In section 7.2 Trusted UAC behavior, it lists 2 different options, > why isnt it possible that if option 1 is followed and a 420 response is > received, that the UAC can default to option 2, i.e perform the necessary > actions to support requested privacy and resubmit the request to the proxy. You can always try another option. > > * Sections 7.3 & 7.4 do not fully describe how the UAS should deal > with an incoming Request containing multiple Remote-Party-IDs. The same > comment applies to the sections on UAC, when it comes to responses > including multiple Remote-Party-IDs. > They are treated similarly to the calling/called subscriber Remote-Party-Id - it's all just identity information and no special action is taken for one party or identity type versus another. > > * Section 7.5 describing proxy behavior says that a proxy many add one > or more Remote-Party-ID headers. > What would be the reason more than one may be included, any examples? There may be multiple types of identity information, for example "user" and "subscriber". -- Flemming > > Thx/gf > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 10:35:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04816 for ; Tue, 5 Mar 2002 10:35:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11151 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 10:35:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08894; Tue, 5 Mar 2002 10:01:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08858 for ; Tue, 5 Mar 2002 10:01:20 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03110 for ; Tue, 5 Mar 2002 10:00:46 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25F0sZ23562 for ; Tue, 5 Mar 2002 17:00:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Mar 2002 17:00:36 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 17:00:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 5 Mar 2002 17:00:36 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790B1@esebe019.NOE.Nokia.com> Thread-Topic: CSeq and Via branch in bis-09 Thread-Index: AcHEVoFn+/ekLoHUSUSDcNw/pXrkJQ== To: X-OriginalArrivalTime: 05 Mar 2002 15:00:36.0470 (UTC) FILETIME=[81A9B960:01C1C456] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA08859 Subject: [Sip] CSeq and Via branch in bis-09 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Section 8.1.3.4 line 1216 in pdf says that "once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7." but says nothing about the CSeq. Should it be incremented by one? Section 8.1.3.5 line 1240 says "This new request SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous." But says nothing about the Via branch. Should it be a new branch id? Thanks, Hisham _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 10:39:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04989 for ; Tue, 5 Mar 2002 10:39:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11418 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 10:39:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08690; Tue, 5 Mar 2002 10:00:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08603 for ; Tue, 5 Mar 2002 10:00:39 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03093; Tue, 5 Mar 2002 10:00:37 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g25ExfZ22898; Tue, 5 Mar 2002 08:59:41 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 08:59:36 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870134@VA02> From: "Peterson, Jon" To: "'David R. Oran'" , "Peterson, Jon" , "'Flemming Andreasen'" , "'Gonzalo Camarillo'" Cc: "'sip'" , "'mmusic'" , "'Fredrik Lindholm (ERA)'" , "'Jonathan Rosemberg'" , wtm@research.att.com Subject: RE: [Sip] Removing security preconditions from manyfolks Date: Tue, 5 Mar 2002 08:59:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Sunday, March 03, 2002 4:32 PM > To: 'Peterson, Jon'; 'Flemming Andreasen'; 'Gonzalo Camarillo' > Cc: 'sip'; 'mmusic'; 'Fredrik Lindholm (ERA)'; 'Jonathan Rosemberg'; > wtm@research.att.com > Subject: RE: [Sip] Removing security preconditions from manyfolks > > > > This is not at all clear to me. What if I want to use IKE or Kerberos to > do the key exchange? What if the key exchange is not in fact tied > directly to the session signaling, but you need to verify via the call > signaling that cached keys have not been thrown away? > Well, agreed that without a particular security mechanism in mind the issue becomes cloudier. I guess this might also boil down to what exact occurrence or set of occurrences would constitute the 'security' precondition being satisfied; it sounds above like you believe the possession of valid keys for encryption and decryption would be such a prerequisite. Undoubtedly, in the most literal-minded sense, having the other party's session key is a prerequisite for sending secured media; I can imagine a number of other potential prerequisites (like mutual e2e authentication, for example). My point was that one cannot start sending secure media until one has received the session key from the other party - and also, that it will be obvious, when a party receives a media packet, whether or not that packet is secured (and what key was used to secure it). RSVP, however, is a very different story. Nothing about how you are going to send a packet changes after your reservation has completed. Nothing about a media packet that you have received is necessarily going to suggest to you that this packet crossed the network over a reserved bandwidth path. So I think there is actually a fundamental difference between the needs of reservation and security, regardless of whether or not the key exchange takes place in SIP. I understand why a COMET and a token in the SDP is useful for reservation, but for security, if they serve anything like the same purpose they seem to serve for reservation, I imagine they would superfluous. That much said, I have no doubt that one could devise a security mechanism that relied on an SDP preconditions flag for some purpose. I suspect though that a simple flag wouldn't ever really suffice, and that you'd probably want something that at least characterized the expected security, or the exact preconditions which have or have not been satisfied. This I feel would likely be outside the scope of manyfolks, and moreover specific to some particular media security scheme. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 11:12:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06638 for ; Tue, 5 Mar 2002 11:12:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13361 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 11:12:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11243; Tue, 5 Mar 2002 10:36:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11212 for ; Tue, 5 Mar 2002 10:36:14 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04876 for ; Tue, 5 Mar 2002 10:36:11 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g25FZYS20537; Tue, 5 Mar 2002 09:35:34 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g25FZRP25956; Tue, 5 Mar 2002 09:35:27 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g25FZPE14440; Tue, 5 Mar 2002 10:35:25 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 10:35:54 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Flemming Andreasen'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Questions/Comments on privacy-04 draft Date: Tue, 5 Mar 2002 10:35:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the clarification. I agree that the untrusted UAC should not include a Remote-Part-ID, but the draft must deal with that case anyways. I still have one more clarification: > > Section 5 says that "If the proxy wants to ensure, that the > calling party can be > identified by the called party, the proxy MUST..." (note the > "if"). So if an untrusted UAC included a Remote-Party-ID, and the proxy is able to *validate* that (via some means) and consequently set the screen to YES, it is then up to the proxy (i.e it is optional) if it wants to include yet another Remote-Party-ID or not. Of course if validation fails or cannot be done, then the proxy *MUST* include a Remote-Party-ID if the request is to be forwarded to another trusted entity. Is this a correct interpretation ? /gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 11:35:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07873 for ; Tue, 5 Mar 2002 11:35:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14692 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 11:35:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13206; Tue, 5 Mar 2002 11:07:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13156 for ; Tue, 5 Mar 2002 11:07:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06328 for ; Tue, 5 Mar 2002 11:07:13 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g25G6jE07263; Tue, 5 Mar 2002 08:06:45 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA09076; Tue, 5 Mar 2002 08:06:44 -0800 (PST) Message-ID: <3C84ED04.2940DD69@cisco.com> Date: Tue, 05 Mar 2002 11:06:29 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "George Foti (LMC)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "George Foti (LMC)" wrote: > Thanks for the clarification. > I agree that the untrusted UAC should not include a Remote-Part-ID, but the > draft must deal with that case anyways. Right (and it does). > > I still have one more clarification: > > > > > Section 5 says that "If the proxy wants to ensure, that the > > calling party can be > > identified by the called party, the proxy MUST..." (note the > > "if"). > > So if an untrusted UAC included a Remote-Party-ID, and the proxy is able to > *validate* that (via some means) and consequently set the screen to YES, it > is then up to the proxy (i.e it is optional) if it wants to include yet > another Remote-Party-ID or not. Yes. > > Of course if validation fails or cannot be done, then the proxy *MUST* > include a Remote-Party-ID if the request is to be forwarded to another > trusted entity. > > Is this a correct interpretation ? > Not entirely. There is no absolute requirement that the proxy includes a Remote-Party-Id. If the proxy can determine the identity of the subscriber, then it SHOULD include a corresponding Remote-Party-Id. However, if the proxy cannot determine the identity, it may reject the request or simply forward it without adding a Remote-Party-Id. -- Flemming > > /gf -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 12:29:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10596 for ; Tue, 5 Mar 2002 12:29:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18926 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 12:29:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15697; Tue, 5 Mar 2002 11:55:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15663 for ; Tue, 5 Mar 2002 11:55:07 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08903 for ; Tue, 5 Mar 2002 11:55:04 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 5 Mar 2002 08:54:27 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Mar 2002 08:54:27 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Mar 2002 08:54:27 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Mar 2002 08:54:26 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 5 Mar 2002 08:51:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Date: Tue, 5 Mar 2002 08:51:33 -0800 Message-ID: Thread-Topic: [Sip] RE: [Sip] [? ?] ?????? ???? ????? thread-index: AcHERKZ0dHLzsVWDQrqujer9YF5shwAIaaFQ From: "Christian Huitema" To: "Rosen, Brian" , "Hussam Jarada" Cc: X-OriginalArrivalTime: 05 Mar 2002 16:51:33.0883 (UTC) FILETIME=[01CA54B0:01C1C466] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA15664 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit An easy way to stop a broad category of spam would be to only accept plain text email... -- Christian Huitema -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, March 05, 2002 4:54 AM To: 'Hussam Jarada' Cc: 'sip@ietf.org' Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? The list is open post; anyone, even non-subscribers are allowed to post. The good part is that you can reply to a message in your area of expertise even if you don't subscribe, and you can reply to a message from an account that is not the one your subscription is from. � The downside is that some Spam gets through.� There is a Spam filter that stops a lot of it, but not all.� Generally, the ADs prefer open posting even at the cost of some Spam.� If the Spam gets very heavy, we can get permission to go closed posting where the moderator (me) has to approve non-subscriber posts.� I don't think we have gotten to this level of Spam yet. � Brian -----Original Message----- From: Hussam Jarada [mailto:hussam.jarada@ulticomdal.com] Sent: Monday, March 04, 2002 5:55 PM To: sip@ietf.org Subject: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Is there's any way we stop this kind of emails in SIP mailing list !!! � Hussam Jarada Sr. Software Eng. Ulticom Inc. Ph. 972-726-9345 Fax. 972-726-9396 � -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of HanBay Sent: Monday, March 04, 2002 4:38 PM To: sip@ietf.org Subject: [Sip] [광 고] 해외교포들의 한국식품 종합쇼핑몰 � _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 12:46:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11565 for ; Tue, 5 Mar 2002 12:46:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20062 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 12:46:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18507; Tue, 5 Mar 2002 12:22:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18477 for ; Tue, 5 Mar 2002 12:22:32 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10319 for ; Tue, 5 Mar 2002 12:22:28 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g25HLel01185; Tue, 5 Mar 2002 11:21:40 -0600 Message-ID: <001901c1c46a$18ab6df0$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: "Rohan Mahy" , , "James M. Polk" References: <4.1.20020304172245.016e82e0@localhost> Subject: Re: [Sip] re: Path as WG item Date: Tue, 5 Mar 2002 11:20:49 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C1C437.CDC7BFF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1C437.CDC7BFF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe you're suggesting that the visited registrar would assign a = temporary identity, then do a third-party registration back to the = user's home registrar applying the temporary identity as a Contact: for = the user's public identity. This approach was discussed in a 3GPP CN1 meeting about a year ago = (Miguel and I spent a long time trying to find an alternative to Path = before loose routing made Path actually work). The problem we noted is = that this approach requires an entirely new authentication mechanism -- = you can't do it readily with something like Digest. Here's the problem. UA sends REGISTER to Visited. How does Visited get = keying information to authenticate UA? Visited then sends a 3rd-party = REGISTER on to Home. How does Visited get keying material to = authenticate to Home? We could presume a coupling at the AAA layer, or some such, but it's = more triggerwork than anybody really wanted to think about. A very similar approach we discussed would be to have the Visited proxy = do the same temporary-identity thing, change the Contact in the REGISTER = to have the temporary identity as its value, then pass the REGISTER on = to Home. This actually works for some authentication models, but I think = it violates the message-integrity protection of enhanced digest. Of course, both of these techniques sahre one moderately annoying flaw = -- they require the visited proxy to be registration-stateful and = persistently maintain the mapping between the temporary and mobile = identities. This makes it hard to build high-capacity proxy clusters, as = one suddenly requires some sort of behind-the-scenes state replication. -- Dean ----- Original Message -----=20 From: James M. Polk=20 To: Rohan Mahy ; sip@ietf.org=20 Sent: Monday, March 04, 2002 5:55 PM Subject: Re: [Sip] re: Path as WG item How about: User1@example.com *registers* with whichever domain that UA is in = locally with the full "User1@example.com"=20 If User1 is in example.com's domain, nothing gets redirected, = everybody's happy If User1's UA is in another domain, then this registration is to that = non-local domain, which replies with a temporary = "User1.example.com@foreign.uk" (or whatever non-local domain example you = want)=20 Upon temporary acceptance to that registration (acknowledgement) back = to User1's UA (now knowing it's in a non-local domain)=20 User1's UA transmits a Redirect Registration back to his/her home = domain Registrar Server (which is now known to be elsewhere) with the = roaming temp address of "User1.example.com@foreign.uk" for logically = where that UA is now and wants to be reached at From here, either User1's domain Registrar Server sends User1's UA an = ACK to convey this is OK (authenticating the UA with its local domain), = or can ACK this temp Redirect to foreign.com's Registrar Server to have = any suggested or required authentication with that domain directly = between locally trusted hosts.=20 Either way, User1's UA needs to have an acknowledgement that this = mobility has been accepted by that UA's local domain (therefore trusting = that all subsequent calls to User1@example.com will be correctly = redirected and the sessions completed) This adds steps to the mobility process, but should: - keep User1's original address as the beginning of the temp = address; - have User1's UA some level of trust future sessions should = come through to this new domain; - keep a simple awareness of communications between the two = domains through this addressing scheme; - keeps all new INVITES going to User1's original domain where = it now knows (with an easy step) where to redirect that INVITE to - creates an almost 3-way handshake between both Registrar = Servers and the roaming UA just a thought..... At 02:59 PM 3/2/2002 -0800, Rohan Mahy wrote: > >Juha, > >Assume: > >REGISTER sip:home.org SIP/2.0 >To: sip:user@home.org >From: sip:user@home.org > >Are you suggesting: > >1) Contact: > >2) Contact: with an additional registration to = xyz.com >(if so, what credentials would I use to authenticate my request?) > >3) something else > >thanks, >-rohan > > > > > > Path fills two needs, and you have omitted the second one. The = second > > one is so that INCOMING calls to me, can be routed from my home = proxy > > through an intermediate proxy that needs to be visited. I think = this is > > well within the scope of an extension to REGISTER, and I know of = no > > other alternative to solve it. This is needed for any kind of > > visiting/roaming network where a local proxy needs to be visited = for > > incoming calls. > > >no i have not omitted that one. i proposed that if i'm visiting in a >network xyz.com, then my home proxy can route incoming calls to the >proxy of xyz.com that in turn knows where to forward the message = within >that network. > >-- 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 ************************************* "People generally demand more respect for their own rights than they = are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike=20 Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com=20 ------=_NextPart_000_0016_01C1C437.CDC7BFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I believe you're suggesting that the = visited=20 registrar would assign a temporary identity, then do a third-party = registration=20 back to the user's home registrar applying the temporary identity as a = Contact:=20 for the user's public identity.
 
This approach was discussed in a 3GPP = CN1 meeting=20 about a year ago (Miguel and I spent a long time trying to find an = alternative=20 to Path before loose routing made Path actually work). The problem we = noted is=20 that this approach requires an entirely new authentication mechanism -- = you=20 can't do it readily with something like Digest.
 
Here's the problem. UA sends REGISTER = to Visited.=20 How does Visited get keying information to authenticate UA? Visited then = sends a=20 3rd-party REGISTER on to Home. How does Visited get keying material to=20 authenticate to Home?
 
We could presume a coupling at the AAA = layer, or=20 some such, but it's more triggerwork than anybody really wanted to think = about.
 
A very similar approach we discussed = would be to=20 have the Visited proxy do the same temporary-identity thing, change the = Contact=20 in the REGISTER to have the temporary identity as its value, then pass = the=20 REGISTER on to Home. This actually works for some authentication models, = but I=20 think it violates the message-integrity protection of enhanced=20 digest.
 
Of course, both of these techniques = sahre one=20 moderately annoying flaw -- they require the visited proxy to be=20 registration-stateful and persistently maintain the mapping between the=20 temporary and mobile identities. This makes it hard to build = high-capacity proxy=20 clusters, as one suddenly requires some sort of behind-the-scenes state=20 replication.
 
--
Dean
 
----- Original Message -----
From:=20 James M. = Polk=20
Sent: Monday, March 04, 2002 = 5:55=20 PM
Subject: Re: [Sip] re: Path as = WG=20 item

How about:

User1@example.com = *registers* with=20 whichever domain that UA is in locally with the full "User1@example.com"

If User1 is in example.com's domain, nothing gets redirected, = everybody's=20 happy

If User1's UA is in another domain, then this registration is to = that=20 non-local domain, which replies with a temporary "User1.example.com@foreign.uk= "=20 (or whatever non-local domain example you want)

Upon temporary acceptance to that registration (acknowledgement) = back to=20 User1's UA (now knowing it's in a non-local domain)

User1's UA transmits a Redirect Registration back to his/her home = domain=20 Registrar Server (which is now known to be elsewhere) with the roaming = temp=20 address of "User1.example.com@foreign.uk" for logically where that UA = is now=20 and wants to be reached at

From here, either User1's domain Registrar Server sends User1's = UA an ACK=20 to convey this is OK (authenticating the UA with its local domain), or = can ACK=20 this temp Redirect to foreign.com's Registrar Server to have any = suggested or=20 required authentication with that domain directly between locally = trusted=20 hosts.

Either way, User1's UA needs to have an acknowledgement that this = mobility has been accepted by that UA's local domain (therefore = trusting that=20 all subsequent calls to User1@example.com will be correctly redirected = and the=20 sessions completed)

This adds steps to the mobility process, but should:
        - = keep=20 User1's original address as the beginning of the temp address;
        - = have=20 User1's UA some level of trust future sessions should come through to = this new=20 domain;
        - = keep a=20 simple awareness of communications between the two domains through = this=20 addressing scheme;
        - = keeps=20 all new INVITES going to User1's original domain where it now knows = (with an=20 easy step) where to redirect that INVITE to
        - = creates=20 an almost 3-way handshake between both Registrar Servers and the = roaming=20 UA

just a thought.....


At 02:59 PM 3/2/2002 -0800, Rohan Mahy wrote:
>
>Juha,
>
>Assume:
>
>REGISTER sip:home.org SIP/2.0
>To: sip:user@home.org
>From: sip:user@home.org
>
>Are you suggesting:
>
>1) Contact: <sip:user@1.2.3.4?Route=3Dxyz.com;lr>
>
>2) Contact: <sip:user@xyz.com>  with an additional = registration to xyz.com
>(if so, what credentials would I use to authenticate my=20 request?)
>
>3) something else
>
>thanks,
>-rohan
>
>
>
><jdr>
> > Path fills two needs, and you have omitted the second = one. The=20 second
> > one is so that INCOMING calls to me, can be routed from = my home=20 proxy
> > through an intermediate proxy that needs to be visited. = I think=20 this is
> > well within the scope of an extension to REGISTER, and = I know=20 of no
> > other alternative to solve it. This is needed for any = kind=20 of
> > visiting/roaming network where a local proxy needs to = be=20 visited for
> > incoming calls.
></jdr>
>
>no i have not omitted that one.  i proposed that if i'm = visiting=20 in a
>network xyz.com, then my home proxy can route incoming calls = to=20 the
>proxy of xyz.com that in turn knows where to forward the = message=20 within
>that network.
>
>-- 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=20 sip

*************************************
"People = generally=20 demand more respect for their own rights than they are willing to = allow for=20 others"

James M. Polk
Consulting Engineer
Office of = the=20 CTO

Cisco Systems
2200 East President George Bush Turnpike=20
Richardson, TX  75082 USA
w) 972.813.5208
f) =20 972.813.5280
www.cisco.com ------=_NextPart_000_0016_01C1C437.CDC7BFF0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 12:53:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12157 for ; Tue, 5 Mar 2002 12:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20456 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 12:53:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18659; Tue, 5 Mar 2002 12:25:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18631 for ; Tue, 5 Mar 2002 12:25:17 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10423 for ; Tue, 5 Mar 2002 12:25:14 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA16711; Tue, 5 Mar 2002 09:24:13 -0800 (PST) Message-Id: <4.1.20020305112309.014395e8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 05 Mar 2002 11:23:47 -0600 To: "Christian Huitema" , "Rosen, Brian" , "Hussam Jarada" From: "James M. Polk" Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1689676396==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1689676396==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 08:51 AM 3/5/2002 -0800, Christian Huitema wrote: >An easy way to stop a broad category of spam would be to only accept plain= =20 >text email... An interesting proposal..... > >-- Christian Huitema > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 >Sent: Tuesday, March 05, 2002 4:54 AM >To: 'Hussam Jarada' >Cc: 'sip@ietf.org' >Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? > >The list is open post; anyone, even non-subscribers are allowed to post. >The good part is that you can reply to a message in your area of expertise even >if you don't subscribe, and you can reply to a message from an account that >is not the one your subscription is from. >=20 >The downside is that some Spam gets through. There is a Spam filter that stops >a lot of it, but not all. Generally, the ADs prefer open posting even at= the >cost of some Spam. If the Spam gets very heavy, we can get permission >to go closed posting where the moderator (me) has to approve non-subscriber >posts. I don't think we have gotten to this level of Spam yet. >=20 >Brian >-----Original Message----- >From: Hussam Jarada [mailto:hussam.jarada@ulticomdal.com] >Sent: Monday, March 04, 2002 5:55 PM >To: sip@ietf.org >Subject: [Sip] RE: [Sip] [? ?] ?????? ???? ????? >Is there's any way we stop this kind of emails in SIP mailing list !!! >=20 >Hussam Jarada >Sr. Software Eng. >Ulticom Inc. >Ph. 972-726-9345 >Fax. 972-726-9396 >=20 >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of HanBay >Sent: Monday, March 04, 2002 4:38 PM >To: sip@ietf.org >Subject: [Sip] [=B1=A4 =B0=ED] =C7=D8=BF=DC=B1=B3=C6=B5=E9=C0=C7 =C7=D1=B1= =B9=BD=C4=C7=B0 =C1=BE=C7=D5=BCî=C7=CE=B8=F4 >=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 ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike=20 Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1689676396==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
At 08:51 AM 3/5/2002 -0800, Christian Huitema wrote:
>An easy way to stop a broad category of spam would be to only accept plain
>text email...

An interesting proposal.....

>
>-- Christian Huitema
>
>-----Original Message-----
>From: Rosen, Brian [mailto:Brian.Ro= sen@marconi.com]
>Sent: Tuesday, March 05, 2002 4:54 AM
>To: 'Hussam Jarada'
>Cc: 'sip@ietf.org'
>Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ?????
>
>The list is open post; anyone, even non-subscribers are allowed to post.
>The good part is that you can reply to a message in your area of expertise even
>if you don't subscribe, and you can reply to a message from an account that
>is not the one your subscription is from.
>
>The downside is that some Spam gets through.  There is a Spam filter that stops
>a lot of it, but not all.  Generally, the ADs prefer open posting even at the
>cost of some Spam.  If the Spam gets very heavy, we can get permission
>to go closed posting where the moderator (me) has to approve non-subscriber
>posts.  I don't think we have gotten to this level of Spam yet.
>
>Brian
>-----Original Message-----
>Sent: Monday, March 04, 2002 5:55 PM
>To: sip@ietf.org
>Subject: [Sip] RE: [Sip] [? ?] ?????? ???? ?????
>Is there's any way we stop this kind of emails in SIP mailing list !!!
>
>Hussam Jarada
>Sr. Software Eng.
>Ulticom Inc.
>Ph. 972-726-9345
>Fax. 972-726-9396
>
>-----Original Message-----
>From: sip-admin@ietf.org [mailto:sip-admi= n@ietf.org]On Behalf Of HanBay
>Sent: Monday, March 04, 2002 4:38 PM
>To: sip@ietf.org
>Subject: [Sip] [=B1=A4 =B0í] ÇØ=BFÜ=B1=B3Æ=B5éÀÇ ÇÑ=B1=B9=BDÄÇ=B0 Á=BEÇÕ=BCîÇÎ=B8ô
>
>
>_______________________________________________
>This list is for NEW development of the core SIP=20 Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1689676396==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 12:57:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12430 for ; Tue, 5 Mar 2002 12:57:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21020 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 12:57:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17734; Tue, 5 Mar 2002 12:08:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17701 for ; Tue, 5 Mar 2002 12:07:52 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09535 for ; Tue, 5 Mar 2002 12:07:49 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g25H6EM08722; Tue, 5 Mar 2002 17:06:14 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 17:06:37 -0000 Message-ID: From: "Mark Watson" To: jh@lohi.eng.song.fi Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 17:06:39 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C468.1D7D7A50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C468.1D7D7A50 Content-Type: text/plain > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 05 March 2002 14:14 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: Dean Willis; sip@ietf.org > Subject: RE: [Sip] Path to Working Group Item > > > > Minor point, but limiting the destinations to which users > can make calls > > *reduces* revenue, because users can make fewer calls and > the service takeup > > will be depressed due to the perceived deficiency. > > mark, > > by limiting freedom i didn't mean limiting the number of end > points that > can be reached, but limiting the way how they can be reached. when i > make a call from a 3gpp phone, i should be able to choose > whether i want > to route the invite to my home proxy or skip my home proxy > and just use > the services of the visited network if the visited network > can give me a > better deal that way. > And indeed you can do this as I described in my earlier mail. There is nothing to stop you establishing a data connection (PDP Context) with the QoS that you want and sending your call over that, via whomever you want (if your terminal supports it). As far as the mobile network is concerned it is providing you with a bit-pipe and they will charge you for that. Mobile operators, however, have a desire to offer what they consider to be an enhanced service by linking together the provision of the bit-pipe with the provision of the application layer service itself - this is what the 3GPP architecture does. Having paid so much for their spectrum licences they quite reasonably want the capability to be more than a bit-pipe. This does not stop you from *using* them as a bit-pipe: whatever works for you/whatever you're prepared to pay for. > also, i should be able to equally choose to use call routing and > gatewaying services of a third party that is not a mobile network > operator at all and still get the same qos service over the wireless > access link as i get when i use the services of the mobile network > operator. > Yes, and I still don't see what is stopping you from doing this. All that is happening with the 3GPP SIP architecture/extensions is that the mobile operators are defining how their own services will work - if they want to make this more complex or different from accessing a SIP service over the Internet it is their own lookout, but there are good reasons for the architecture and extensions in terms of the service it enables them to offer to their customers, including differing charging models. > with this background you should understand why i don't at all like the > idea of breaking the sip protocol architecture and making > registration a > prerequisite for making calls and thus giving the mobile network > operators yet another brick for their wall. > Registration is a pre-requisite for accessing services of the 3GPP IP Multimedia Subsystem. 3GPP is not (cannot) make registration a pre-requiste for accessing other SIP-based networks over wireless access. However, in the case of this particular extensions, I think enough examples have been given to show its utility in applications other then the 3GPP IMS, and so it warrents IETF standardisation. By contrast a number of other 3GPP requirements have been judged to be entirely 3GPP-specific, and for these the IETF has suggested that 3GPP define its own solutions. > -- juha > > ------_=_NextPart_001_01C1C468.1D7D7A50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Path to Working Group Item

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 05 March 2002 14:14
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: Dean Willis; sip@ietf.org
> Subject: RE: [Sip] Path to Working Group = Item
>
>
>  > Minor point, but limiting the = destinations to which users
> can make calls
>  > *reduces* revenue, because users can = make fewer calls and
> the service takeup
>  > will be depressed due to the = perceived deficiency.
>
> mark,
>
> by limiting freedom i didn't mean limiting the = number of end
> points that
> can be reached, but limiting the way how they = can be reached.  when i
> make a call from a 3gpp phone, i should be able = to choose
> whether i want
> to route the invite to my home proxy or skip my = home proxy
> and just use
> the services of the visited network if the = visited network
> can give me a
> better deal that way.
>

And indeed you can do this as I described in my = earlier mail. There is nothing to stop you establishing a data = connection (PDP Context) with the QoS that you want and sending your = call over that, via whomever you want (if your terminal supports = it).

As far as the mobile network is concerned it is = providing you with a bit-pipe and they will charge you for that.

Mobile operators, however, have a desire to offer = what they consider to be an enhanced service by linking together the = provision of the bit-pipe with the provision of the application layer = service itself - this is what the 3GPP architecture does. Having paid = so much for their spectrum licences they quite reasonably want the = capability to be more than a bit-pipe.

This does not stop you from *using* them as a = bit-pipe: whatever works for you/whatever you're prepared to pay = for.

> also, i should be able to equally choose to use = call routing and
> gatewaying services of a third party that is = not a mobile network
> operator at all and still get the same qos = service over the wireless
> access link as i get when i use the services of = the mobile network
> operator.
>

Yes, and I still don't see what is stopping you from = doing this. All that is happening with the 3GPP SIP = architecture/extensions is that the mobile operators are defining how = their own services will work - if they want to make this more complex = or different from accessing a SIP service over the Internet it is their = own lookout, but there are good reasons for the architecture and = extensions in terms of the service it enables them to offer to their = customers, including differing charging models.

> with this background you should understand why i = don't at all like the
> idea of breaking the sip protocol architecture = and making
> registration a
> prerequisite for making calls and thus giving = the mobile network
> operators yet another brick for their = wall.
>

Registration is a pre-requisite for accessing = services of the 3GPP IP Multimedia Subsystem. 3GPP is not (cannot) make = registration a pre-requiste for accessing other SIP-based networks over = wireless access.

However, in the case of this particular extensions, I = think enough examples have been given to show its utility in = applications other then the 3GPP IMS, and so it warrents IETF = standardisation. By contrast a number of other 3GPP requirements have = been judged to be entirely 3GPP-specific, and for these the IETF has = suggested that 3GPP define its own solutions.


> -- juha
>
>

------_=_NextPart_001_01C1C468.1D7D7A50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 12:58:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12540 for ; Tue, 5 Mar 2002 12:58:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21257 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 12:58:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17804; Tue, 5 Mar 2002 12:09:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17773 for ; Tue, 5 Mar 2002 12:09:32 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09661 for ; Tue, 5 Mar 2002 12:09:29 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g25H8gl01093; Tue, 5 Mar 2002 11:08:42 -0600 Message-ID: <000f01c1c468$48dcd740$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: , "Jonathan Rosenberg" Cc: References: <65256B72.006FB368.00@sampark.hss.hns.com> Subject: Re: [Sip] Clarification relating to the Path header usage. Date: Tue, 5 Mar 2002 11:07:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Siddarth asked: > > Path fills two needs, and you have omitted the second > > one. The second one is so that INCOMING calls to me, > > can be routed from my home proxy through an intermediate > > proxy that needs to be visited. I think this is well > > within the scope of an extension to REGISTER, and I know > > of no other alternative to solve it. This is needed for > > any kind of visiting/roaming network where a local proxy > > needs to be visited for incoming calls. > > My doubt is regarding this second usage. This works well > when the home proxy knows that there is one and only one > hop that is to be covered between the home proxy and me. > In case there are more than one hops to be traversed, does > each hop in the path need to remember the previous hop? > > Consider the scenario: > > UA1 --> P1 --> P2 --> registrar > | > | > home_proxy <-- UA2 > > registrar remembers Path as , for reaching > UA1. Now UA2 tries to reach UA1 via is home proxy. The query > with the registrar returns that both P2 and P1 should be > contacted (in that order). > > So far so good. Now, how does "home_proxy" convey the information > that P2 should send the request to P1? It cannot add a Route > header. Should home_proxy add the Path header to the request > from UA2 and *somehow* make P1 understand this is the next hop? > If so, how? Details for this are missing in the draft.... > Or am I missing something here? There can be as many nides recorded in the Path (or REGISTER Record-Route if you want to call it that) as needed. If I'm reading this right: The thing you are calling "registrar" need s to also be UA1's home proxy. So it actually looks more like this UA1---P1---P2---UA1HOME/REGISTRAR---UA2HOME---UA2 UA2 sends an INVITE through its home proxy, which uses whatever resolution mechanism (such as DNS) needed to find UA1's home proxy and send the INVITE there. UA1's home proxy stored the Path or REGISTER Record-Route (or whatever we call it) and attaches this as new loose-routing elements on the INVITE. This results in transiting of P2 and P1 en route to UA1. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:09:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13351 for ; Tue, 5 Mar 2002 13:09:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23058 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:09:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20560; Tue, 5 Mar 2002 12:53:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20381 for ; Tue, 5 Mar 2002 12:53:33 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12137 for ; Tue, 5 Mar 2002 12:52:58 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g25Hpql01379; Tue, 5 Mar 2002 11:51:52 -0600 Message-ID: <004e01c1c46e$50600040$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: , "Mark Watson" Cc: "Rosen, Brian" , References: <15492.56325.337875.744049@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 11:51:00 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha says: > in sip, register request accomplishes one and only one thing: lets > others to learn that i'm available for calls and how their calls can > reach me. the path proposal on the table is changing that in a > fundamental way by establishing to the registering party a service route > that it should be using when it makes calls. that part of the proposal > breaks the sip protocol architecture and is thus unacceptable. Are you saying that it is in general unacceptable to use proxies to provide value-added services for outbound calls? I'd find that a hard position to support, as one of the big advantages claimed for SIP has been its ability to enable value-added services for both inbound and outbound calls. I give some examples in another post on this topic. So it's just a question of figuring out where to get those outbound services from . . . The Path proposal doesn't (or at least shouldn't, if it does let's correct the wording ) REQUIRE that the UA exclusivelt use a specific technique to discover an exclusive service proxy. It simply provides an option for doing so. I'd argue that this approach MAY inform the registering party of a service route that MAY be used to get to to certain services. There MAY be other mechanisms available to convey this information as well -- this draft certainly doesn't claim to be the ONLY way to do this. Now certain operators in certain networks providing phones to certain users MAY set the phones up to where such usage is the default condition, but that doesn't violate any architectural principle any more than does giving away free browsers that have Yahoo set as their home page. Operators are free to shoot themselves in both feet if they want to, and I'm sure many will do so repeatedly . . . fortunately, others MAY not. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:17:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13869 for ; Tue, 5 Mar 2002 13:17:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23729 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19820; Tue, 5 Mar 2002 12:40:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19791 for ; Tue, 5 Mar 2002 12:40:41 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11242 for ; Tue, 5 Mar 2002 12:40:39 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g25Hdal01304; Tue, 5 Mar 2002 11:39:36 -0600 Message-ID: <002f01c1c46c$99b8c620$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: Cc: References: <15488.51579.504863.337657@harjus.eng.song.fi><3C811FAA.F5C5D4F8@dynamicsoft.com><15489.10785.323279.964564@harjus.eng.song.fi><016701c1c23e$2b8c7230$133fed0c@C1893415A><15489.50086.993050.645336@harjus.eng.song.fi><003901c1c280$355c2c00$133fed0c@C1893415A><15489.54093.327411.43727@harjus.eng.song.fi><002101c1c2f7$6951e550$133fed0c@C1893415A><15490.37845.661770.900419@harjus.eng.song.fi><004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2><15491.3421.688850.744507@harjus.eng.song.fi><008901c1c39a$69ad27a0$133fed0c@C1893415A> <15492.34464.981571.881300@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 11:38:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > So would you propose to call the header-for-use-with-REGISTER Record-Route > > instead of Path? > > no. as i said, there is no need to invent a new header name. we can > simply define the semantics of record-route for register messages. > behavior of proxies would be exactly the same as for record routing > other messages. you simply add a new configuration variable > "recordRouteRegisterMessages" to which the operator of the proxy can > assign a true or false value. I suppose its a philosphical distinction as to whether one calls RecordRoute on REGISTER a "new" header" (as it isn't defined for REGISTER now) or a "define the semantics for record-route on REGISTER messages". In either case it's new functionality. > the semantics at the registrar were already discussed yesterday: the > registrar would add the recorded route along with the contact address in > to its database. when the proxy of the registrar then receives a request > bound for a local user, it would forward the request towards the contact > address and add the recorded route to the route header of the request. Yes, that's exactly what the Path draft proposes be done with the record information on user-terminated calls. > the only reason why we would need to invent a new header name would be > if using record routing of register request would not be backwards > compatible with rfc 2543, i.e., if an old proxy that gets a register > request that includes record-route, would break the request. i don't > think that that would happen, because record-route has always been an > optional header in register request. Hey -- The REST of you people? How do you feel about calling this functionality Record-Route for REGISTER as opposed to Path for REGISTER? > this solution would be fully compatible with sip protocol architecture, > where a register request serves the purpose of others being able to > reach me and where i have no need to send a register request as a > prerequisite of me reaching others. Well' I'd argue that it's fully compatible with the architecture whether it's called Record-Route, Path, or Fritz-the-Far-Out-Header. But remember there were two problems being solved: 1) How to get user-terminated calls back to the user when there are intermediate proxies, which we've apparently solved here -- we're just arguing about the name. and 2) How to get user-originated calls routed through a home service proxy when there are intermediate proxies. There is only a need to send a REGISTER request as a prerequisite for reaching others if 1) One wishes to use the services of a non-adjacent intermediate proxy, and 2) one is using the REGISTER process to discover the route to that intermediate proxy. When would one do something like this? I don't know about the other guys, but I have speed-dialing functions on some of my proxies. Sure, this could be in the UA, but remember I'm using a primitive old 3Com phone that doesn't have that capability. So I've got this proxy that knows "If dwillis sends an invite to "1", proxy that to sip:madameleatherette@disciplineinstruction.com" (ok, I just made that up, my real speed dial list is boring), because that's just too long a URL to type on a 10-key keypad. I don't HAVE to use this service proxy, but I want to be able to use it when I want to use it, and that's a valid architectural principle. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:26:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14831 for ; Tue, 5 Mar 2002 13:26:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24410 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:26:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21139; Tue, 5 Mar 2002 12:57:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21051 for ; Tue, 5 Mar 2002 12:57:35 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12471 for ; Tue, 5 Mar 2002 12:57:33 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g25HuVl01423; Tue, 5 Mar 2002 11:56:31 -0600 Message-ID: <007201c1c46e$f6f284a0$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: "Sean Olson" , Cc: References: <20020305175500.54887.qmail@web11602.mail.yahoo.com> Subject: Re: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 11:55:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Sean Olson" To: "Dean Willis" ; Cc: Sent: Tuesday, March 05, 2002 11:55 AM Subject: Re: [Sip] Path to Working Group Item > > Hey -- The REST of you people? How do you feel about > > calling this > > functionality Record-Route for REGISTER as opposed > > to Path for REGISTER? > > I was opposed to this when the Path mechanism was > first being discussed. If we define the functionality > of Record-Route: for REGISTER, it should follow the > same general idea as Record-Route: for INVITE. That > is, it should define how subsequent requests within > the same dialog are routed. This is not the same > thing that Path: is doing. Well, there ARE no subsequent requests within the same dialog, as REGISTER doesn't create a dialog . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:29:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15110 for ; Tue, 5 Mar 2002 13:29:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24586 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:29:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21358; Tue, 5 Mar 2002 12:59:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21327 for ; Tue, 5 Mar 2002 12:59:23 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12603 for ; Tue, 5 Mar 2002 12:59:21 -0500 (EST) Message-ID: <20020305175922.54333.qmail@web11606.mail.yahoo.com> Received: from [207.46.137.9] by web11606.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 09:59:22 PST Date: Tue, 5 Mar 2002 09:59:22 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Path to Working Group Item To: Dean Willis , jh@lohi.eng.song.fi Cc: sip@ietf.org In-Reply-To: <007201c1c46e$f6f284a0$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Exactly ... --- Dean Willis wrote: > > ----- Original Message ----- > From: "Sean Olson" > To: "Dean Willis" ; > > Cc: > Sent: Tuesday, March 05, 2002 11:55 AM > Subject: Re: [Sip] Path to Working Group Item > > > > > Hey -- The REST of you people? How do you feel > about > > > calling this > > > functionality Record-Route for REGISTER as > opposed > > > to Path for REGISTER? > > > > I was opposed to this when the Path mechanism was > > first being discussed. If we define the > functionality > > of Record-Route: for REGISTER, it should follow > the > > same general idea as Record-Route: for INVITE. > That > > is, it should define how subsequent requests > within > > the same dialog are routed. This is not the same > > thing that Path: is doing. > > Well, there ARE no subsequent requests within the > same dialog, as REGISTER > doesn't create a dialog . . . > > -- > Dean > ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:30:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15378 for ; Tue, 5 Mar 2002 13:30:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24939 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:30:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20748; Tue, 5 Mar 2002 12:55:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20700 for ; Tue, 5 Mar 2002 12:55:02 -0500 (EST) Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12313 for ; Tue, 5 Mar 2002 12:55:00 -0500 (EST) Message-ID: <20020305175500.54887.qmail@web11602.mail.yahoo.com> Received: from [207.46.137.11] by web11602.mail.yahoo.com via HTTP; Tue, 05 Mar 2002 09:55:00 PST Date: Tue, 5 Mar 2002 09:55:00 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Path to Working Group Item To: Dean Willis , jh@lohi.eng.song.fi Cc: sip@ietf.org In-Reply-To: <002f01c1c46c$99b8c620$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Hey -- The REST of you people? How do you feel about > calling this > functionality Record-Route for REGISTER as opposed > to Path for REGISTER? I was opposed to this when the Path mechanism was first being discussed. If we define the functionality of Record-Route: for REGISTER, it should follow the same general idea as Record-Route: for INVITE. That is, it should define how subsequent requests within the same dialog are routed. This is not the same thing that Path: is doing. /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:36:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15926 for ; Tue, 5 Mar 2002 13:36:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25457 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:36:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22992; Tue, 5 Mar 2002 13:07:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22947 for ; Tue, 5 Mar 2002 13:07:45 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13308 for ; Tue, 5 Mar 2002 13:07:43 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g25I7fh11022; Tue, 5 Mar 2002 12:07:41 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g25I7eP07355; Tue, 5 Mar 2002 12:07:40 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g25I7dE24074; Tue, 5 Mar 2002 13:07:40 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 13:08:09 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374C0@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Dean Willis'" , "'jh@lohi.eng.song.fi'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 13:07:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org PATH. The name is known to many people, the 3GPP, the cable labs, etc. It is used in dozens, if not more, *large size* documents on both fronts. As far as I can tell there is only one lone voice that does not like the name PATH. We dont need to redit all of the above documents & re-educate people who actually have a vested interest just for philosophical stands. There must be more compelling reasons to that. I havent seen any. Rgds/gf > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, March 05, 2002 12:39 PM > To: jh@lohi.eng.song.fi > Cc: sip@ietf.org > Subject: Re: [Sip] Path to Working Group Item > > > > > > So would you propose to call the header-for-use-with-REGISTER > Record-Route > > > instead of Path? > > > > no. as i said, there is no need to invent a new header name. we can > > simply define the semantics of record-route for register messages. > > behavior of proxies would be exactly the same as for record routing > > other messages. you simply add a new configuration variable > > "recordRouteRegisterMessages" to which the operator of the proxy can > > assign a true or false value. > > > I suppose its a philosphical distinction as to whether one > calls RecordRoute > on REGISTER a "new" header" (as it isn't defined for REGISTER > now) or a > "define the semantics for record-route on REGISTER messages". > In either case > it's new functionality. > > > the semantics at the registrar were already discussed yesterday: the > > registrar would add the recorded route along with the > contact address in > > to its database. when the proxy of the registrar then > receives a request > > bound for a local user, it would forward the request > towards the contact > > address and add the recorded route to the route header of > the request. > > Yes, that's exactly what the Path draft proposes be done with > the record > information on user-terminated calls. > > > the only reason why we would need to invent a new header > name would be > > if using record routing of register request would not be backwards > > compatible with rfc 2543, i.e., if an old proxy that gets a register > > request that includes record-route, would break the > request. i don't > > think that that would happen, because record-route has > always been an > > optional header in register request. > > Hey -- The REST of you people? How do you feel about calling this > functionality Record-Route for REGISTER as opposed to Path > for REGISTER? > > > this solution would be fully compatible with sip protocol > architecture, > > where a register request serves the purpose of others being able to > > reach me and where i have no need to send a register request as a > > prerequisite of me reaching others. > > Well' I'd argue that it's fully compatible with the > architecture whether > it's called Record-Route, Path, or Fritz-the-Far-Out-Header. > > But remember there were two problems being solved: 1) How to get > user-terminated calls back to the user when there are > intermediate proxies, > which we've apparently solved here -- we're just arguing > about the name. and > 2) How to get user-originated calls routed through a home > service proxy when > there are intermediate proxies. > > There is only a need to send a REGISTER request as a prerequisite for > reaching others if 1) One wishes to use the services of a non-adjacent > intermediate proxy, and 2) one is using the REGISTER process > to discover the > route to that intermediate proxy. When would one do something > like this? I > don't know about the other guys, but I have speed-dialing > functions on some > of my proxies. Sure, this could be in the UA, but remember I'm using a > primitive old 3Com phone that doesn't have that capability. > So I've got this > proxy that knows "If dwillis sends an invite to "1", proxy that to > sip:madameleatherette@disciplineinstruction.com" (ok, I just > made that up, > my real speed dial list is boring), because that's just too > long a URL to > type on a 10-key keypad. I don't HAVE to use this service > proxy, but I want > to be able to use it when I want to use it, and that's a > valid architectural > principle. > > -- > Dean > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:43:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19853 for ; Tue, 5 Mar 2002 13:43:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25742 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21408; Tue, 5 Mar 2002 12:59:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21374 for ; Tue, 5 Mar 2002 12:59:35 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12613 for ; Tue, 5 Mar 2002 12:59:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g25Hxr6Y026026; Tue, 5 Mar 2002 12:59:53 -0500 (EST) Message-ID: <3C850760.B46E253A@dynamicsoft.com> Date: Tue, 05 Mar 2002 12:58:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: sip@ietf.org Subject: Re: [Sip] CSeq and Via branch in bis-09 References: <2038BCC78B1AD641891A0D1AE133DBB77790B1@esebe019.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > Section 8.1.3.4 line 1216 in pdf says that > > "once the new request has been constructed, it is sent using a new > client transaction, and therefore > MUST have a new branch ID in the top Via field as discussed in Section > 8.1.1.7." > > but says nothing about the CSeq. Should it be incremented by one? It can be; I think its mildly better if its not, so that it can be detected as a merged request if a second copy arrives at a UAS. > > Section 8.1.3.5 line 1240 says > > "This new request SHOULD have the same value of the Call-ID, To, and > >From of the previous request, > but the CSeq should contain a new sequence number that is one higher > than the previous." > > But says nothing about the Via branch. Should it be a new branch id? Yes, definitely! The branch ID is unique for each distinct request sent by a client (excepting CANCEL and ACK-non-2xx). That is very important. Branch ID computation is discussed in another section. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Tue Mar 5 13:43:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20107 for ; Tue, 5 Mar 2002 13:43:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25760 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:43:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23613; Tue, 5 Mar 2002 13:15:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23584 for ; Tue, 5 Mar 2002 13:15:53 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13801 for ; Tue, 5 Mar 2002 13:15:51 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25466; Tue, 5 Mar 2002 13:15:19 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27588; Tue, 5 Mar 2002 13:15:20 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 13:15:19 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CBC2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Christian Huitema'" , Hussam Jarada Cc: sip@ietf.org Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? Date: Tue, 5 Mar 2002 13:15:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA23587 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Two things: Mailman doesn't have a filter for ASCII only. I recently received some guidance from our ADs that will allow us to change the list to subscriber post, with moderator approval of non-subscribers. There are some arrangements I have to make, but as soon as they are done, we should see this kind of spam decrease. Brian > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Tuesday, March 05, 2002 11:52 AM > To: Rosen, Brian; Hussam Jarada > Cc: sip@ietf.org > Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? > > > An easy way to stop a broad category of spam would be to only > accept plain text email... > > -- Christian Huitema > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, March 05, 2002 4:54 AM > To: 'Hussam Jarada' > Cc: 'sip@ietf.org' > Subject: RE: [Sip] RE: [Sip] [? ?] ?????? ???? ????? > > The list is open post; anyone, even non-subscribers are > allowed to post. > The good part is that you can reply to a message in your area > of expertise even > if you don't subscribe, and you can reply to a message from > an account that > is not the one your subscription is from. > � > The downside is that some Spam gets through.� There is a Spam > filter that stops > a lot of it, but not all.� Generally, the ADs prefer open > posting even at the > cost of some Spam.� If the Spam gets very heavy, we can get permission > to go closed posting where the moderator (me) has to approve > non-subscriber > posts.� I don't think we have gotten to this level of Spam yet. > � > Brian > -----Original Message----- > From: Hussam Jarada [mailto:hussam.jarada@ulticomdal.com] > Sent: Monday, March 04, 2002 5:55 PM > To: sip@ietf.org > Subject: [Sip] RE: [Sip] [? ?] ?????? ???? ????? > Is there's any way we stop this kind of emails in SIP mailing list !!! > � > Hussam Jarada > Sr. Software Eng. > Ulticom Inc. > Ph. 972-726-9345 > Fax. 972-726-9396 > � > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of HanBay > Sent: Monday, March 04, 2002 4:38 PM > To: sip@ietf.org > Subject: [Sip] [광 고] 해외교포들의 한국식품 종합쇼핑몰 > � > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 13:48:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25414 for ; Tue, 5 Mar 2002 13:48:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25993 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:48:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24018; Tue, 5 Mar 2002 13:21:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23981 for ; Tue, 5 Mar 2002 13:21:12 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14288 for ; Tue, 5 Mar 2002 13:21:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g25ILU6Y026039; Tue, 5 Mar 2002 13:21:30 -0500 (EST) Message-ID: <3C850C71.58DEFBAF@dynamicsoft.com> Date: Tue, 05 Mar 2002 13:20:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "George Foti (LMC)" , sip@ietf.org Subject: Re: [Sip] UPDATE Method & Glare References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > > I agree - this needs to be described. I've added text about it. > > If I remember some earlier discussions correctly, then if you receive > an UPDATE whilst waiting for a response to an UPDATE that you send > yourself, the you should immediately reject the UPDATE, but with what > failure response I do not know. 491. Its in 4.2 of bis-09. > > Do we require a specific failure response for glare ? I guess you need > to know that it is worth retrying after some random interval. Yes, exactly. > > Also, if you are waiting for a repsonse to an UPDATE you have sent, > and you receive an UPDATE which is a retransmit of one you have > previously responded to (presumably because your original response was > lost), I believe you should just repeat your original response and > continue waiting for the response to your UPDATE. Of course. That is handled in the transaction layer, which will retransmit the response. > > Your UPDATE will probably be rejected, because the other guy thinks > there is glare, but it is possible for both UPDATES to suceed if > messages swap order in transit, but this is not a problem. THere is no way for both to succeed. > > Is this taken care of by the transaction layer in SIP or does it need > to be explicitly described ? Retransmits are discussed in the transaction layer only. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Tue Mar 5 13:52:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29476 for ; Tue, 5 Mar 2002 13:52:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA26129 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 13:52:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22833; Tue, 5 Mar 2002 13:06:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22801 for ; Tue, 5 Mar 2002 13:06:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13150 for ; Tue, 5 Mar 2002 13:05:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g25I6J6Y026032; Tue, 5 Mar 2002 13:06:21 -0500 (EST) Message-ID: <3C8508E3.1EE2F86C@dynamicsoft.com> Date: Tue, 05 Mar 2002 13:05:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tan Ya-Ching ICM N PG U ID A 1 CC: Robert Sparks , SIP Subject: Re: [Sip] Question about Section 12.2 Requests within a Dialog References: <5B4D0C5BA65ECA46969C1419122317E60817A6@mchh161e> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Tan Ya-Ching ICM N PG U ID A 1 wrote: > > | The re-INVITE changes the remote URI. > | > | Here is an example. I send an INVITE with a Cotnact header of > | sip:@. The call is established. A BYE, > | re-INVITE, or other mid-dialog request will arrive to me with this URI > | in the request URI. I can use that for whatever purposes I like. If I > | wish to change it, I can issue a re-INVITE, which updates it at the > | other side. > | > > I have a question about the sentence "I can use that (URI learned from > Contact header) for whatever purposes I like". What is the scope of such > a > URI ? Actually the scope of the URI is global. THis is because certain services, like attended transfer, will require it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Tue Mar 5 14:00:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08650 for ; Tue, 5 Mar 2002 14:00:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26871 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 14:00:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24536; Tue, 5 Mar 2002 13:27:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24506 for ; Tue, 5 Mar 2002 13:27:54 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14986 for ; Tue, 5 Mar 2002 13:27:51 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA28877; Tue, 5 Mar 2002 13:27:46 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g25IRj6X013057; Tue, 5 Mar 2002 13:27:45 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g25IRiHQ013054; Tue, 5 Mar 2002 13:27:44 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.3616.195538.277290@grandcentral.cs.columbia.edu> Date: Tue, 5 Mar 2002 13:27:44 -0500 To: "Dean Willis" Cc: , Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <002f01c1c46c$99b8c620$bb036e3f@TXDWILLIS2> References: <15488.51579.504863.337657@harjus.eng.song.fi> <3C811FAA.F5C5D4F8@dynamicsoft.com> <15489.10785.323279.964564@harjus.eng.song.fi> <016701c1c23e$2b8c7230$133fed0c@C1893415A> <15489.50086.993050.645336@harjus.eng.song.fi> <003901c1c280$355c2c00$133fed0c@C1893415A> <15489.54093.327411.43727@harjus.eng.song.fi> <002101c1c2f7$6951e550$133fed0c@C1893415A> <15490.37845.661770.900419@harjus.eng.song.fi> <004c01c1c330$9a21fdd0$b27ba8c0@TXDWILLIS2> <15491.3421.688850.744507@harjus.eng.song.fi> <008901c1c39a$69ad27a0$133fed0c@C1893415A> <15492.34464.981571.881300@harjus.eng.song.fi> <002f01c1c46c$99b8c620$bb036e3f@TXDWILLIS2> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Tuesday, March 5 2002, "Dean Willis" wrote to ", " saying: > Hey -- The REST of you people? How do you feel about calling this > functionality Record-Route for REGISTER as opposed to Path for REGISTER? Note the comment in section 10.3 of bis-09: A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record-Route header field value. This is the justification for the text that says that both UACs and UASs MUST ignore Record-Route in REGISTER requests and responses. This was, indeed, exactly the motivation for calling this header something other than Record-Route. -- 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 daemon@optimus.ietf.org Tue Mar 5 14:00:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09047 for ; Tue, 5 Mar 2002 14:00:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26983 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 14:01:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25198; Tue, 5 Mar 2002 13:31:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25100 for ; Tue, 5 Mar 2002 13:31:39 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15456 for ; Tue, 5 Mar 2002 13:31:36 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g25IVPh26813; Tue, 5 Mar 2002 12:31:25 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g25IVPj13169; Tue, 5 Mar 2002 12:31:25 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g25IVOE25696; Tue, 5 Mar 2002 13:31:24 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 13:31:54 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374C3@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Jonathan Rosenberg'" , "'Mark Watson'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] UPDATE Method & Glare Date: Tue, 5 Mar 2002 13:31:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Has UPDATE-02 been issued /gf > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, March 05, 2002 1:21 PM > To: Mark Watson > Cc: George Foti (LMC); sip@ietf.org > Subject: Re: [Sip] UPDATE Method & Glare > > > > > Mark Watson wrote: > > > > I agree - this needs to be described. > > I've added text about it. > > > > > If I remember some earlier discussions correctly, then if > you receive > > an UPDATE whilst waiting for a response to an UPDATE that you send > > yourself, the you should immediately reject the UPDATE, but > with what > > failure response I do not know. > > 491. Its in 4.2 of bis-09. > > > > > Do we require a specific failure response for glare ? I > guess you need > > to know that it is worth retrying after some random interval. > > Yes, exactly. > > > > > Also, if you are waiting for a repsonse to an UPDATE you have sent, > > and you receive an UPDATE which is a retransmit of one you have > > previously responded to (presumably because your original > response was > > lost), I believe you should just repeat your original response and > > continue waiting for the response to your UPDATE. > > Of course. That is handled in the transaction layer, which will > retransmit the response. > > > > > Your UPDATE will probably be rejected, because the other guy thinks > > there is glare, but it is possible for both UPDATES to suceed if > > messages swap order in transit, but this is not a problem. > > THere is no way for both to succeed. > > > > > Is this taken care of by the transaction layer in SIP or > does it need > > to be explicitly described ? > > Retransmits are discussed in the transaction layer only. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Tue Mar 5 14:47:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23754 for ; Tue, 5 Mar 2002 14:47:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00165 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 14:47:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28050; Tue, 5 Mar 2002 14:18:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28016 for ; Tue, 5 Mar 2002 14:18:31 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21770 for ; Tue, 5 Mar 2002 14:18:28 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iKSD-0007Al-00; Tue, 05 Mar 2002 21:18:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.6660.935483.328170@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 21:18:28 +0200 To: "Dean Willis" Cc: Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <002f01c1c46c$99b8c620$bb036e3f@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Well' I'd argue that it's fully compatible with the architecture whether > it's called Record-Route, Path, or Fritz-the-Far-Out-Header. i agree with that, but as i have said too many times already, the real problem is not the name, but piggy packing with the register message service location information. see the previous message for why. > But remember there were two problems being solved: 1) How to get > user-terminated calls back to the user when there are intermediate proxies, > which we've apparently solved here -- we're just arguing about the name. and > 2) How to get user-originated calls routed through a home service proxy when > there are intermediate proxies. sip solution to that is (a) use dns to locate the home service proxy and use dhcp learned outbound proxy information + loose source route to the home proxy to send the message out. > There is only a need to send a REGISTER request as a prerequisite for > reaching others if 1) One wishes to use the services of a non-adjacent > intermediate proxy, and 2) one is using the REGISTER process to discover the > route to that intermediate proxy. see above. -- 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 daemon@optimus.ietf.org Tue Mar 5 14:53:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23971 for ; Tue, 5 Mar 2002 14:53:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00374 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 14:53:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28516; Tue, 5 Mar 2002 14:23:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28486 for ; Tue, 5 Mar 2002 14:23:56 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22166 for ; Tue, 5 Mar 2002 14:23:53 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iKXQ-0007Az-00; Tue, 05 Mar 2002 21:23:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.6984.820616.467330@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 21:23:52 +0200 To: "George Foti (LMC)" Cc: "'Dean Willis'" , "'sip@ietf.org'" Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C0374C0@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C0374C0@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > As far as I can tell there is only one lone voice that does not like the > name PATH. name is not a big deal to me as long as you take the functions out from the path message that don't belong to the registering process, i.e., letting others to reach the registering party. by the way, my suggestion is record-register-route, which is intuitive to people who know what record-route does. -- 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 daemon@optimus.ietf.org Tue Mar 5 14:59:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24252 for ; Tue, 5 Mar 2002 14:59:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00596 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 14:59:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27579; Tue, 5 Mar 2002 14:10:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27548 for ; Tue, 5 Mar 2002 14:10:11 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18386 for ; Tue, 5 Mar 2002 14:10:08 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iKK7-0007Ab-00; Tue, 05 Mar 2002 21:10:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.6159.403666.553289@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 21:10:07 +0200 To: "Dean Willis" Cc: "Mark Watson" , "Rosen, Brian" , Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <004e01c1c46e$50600040$bb036e3f@TXDWILLIS2> References: <15492.56325.337875.744049@harjus.eng.song.fi> <004e01c1c46e$50600040$bb036e3f@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Are you saying that it is in general unacceptable to use proxies to provide > value-added services for outbound calls? no, i don't object to that, but that information has nothing to do with register message, whose function is to let others to reach the registering party. > So it's just a question of > figuring out where to get those outbound services from . . . sip uses dns for that purpose, not something piggy packed to register message, whose purpose has nothing to do with outbound calls and that a sip ua doesn't even need to send in order to make outbound calls. in sip we simply can't have a service that an ua is not able to locate unless it first registers itself. that kind of requirement totally break the sip protocol architecture. if you are not happy with dns for locating services, you can in the 3gpp group either invent another sip message for that purpose. > The Path proposal doesn't (or at least shouldn't, if it does let's correct > the wording ) REQUIRE that the UA exclusivelt use a specific technique to > discover an exclusive service proxy. It simply provides an option for doing > so. what kind of option is that a 3gpp ua can't make any calls without first registering itself and if it does register itself, gets back a service route that is must use in order to make those calls. i don't see any optionality in that. -- 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 daemon@optimus.ietf.org Tue Mar 5 15:07:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24682 for ; Tue, 5 Mar 2002 15:07:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01461 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 15:07:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29930; Tue, 5 Mar 2002 14:43:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29891 for ; Tue, 5 Mar 2002 14:43:52 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23538 for ; Tue, 5 Mar 2002 14:43:49 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 5 Mar 2002 11:43:20 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Mar 2002 11:43:20 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Mar 2002 11:43:20 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Mar 2002 11:43:19 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 5 Mar 2002 11:40:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 11:40:27 -0800 Message-ID: Thread-Topic: [Sip] Path to Working Group Item thread-index: AcHEbo8q+6KYT9HfTK6A0BVWBX0/QQADq8ew From: "Christian Huitema" To: "Dean Willis" , , "Mark Watson" Cc: "Rosen, Brian" , X-OriginalArrivalTime: 05 Mar 2002 19:40:27.0235 (UTC) FILETIME=[99BD2330:01C1C47D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA29892 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Juha says: > > in sip, register request accomplishes one and only one thing: lets > > others to learn that i'm available for calls and how their calls can > > reach me. the path proposal on the table is changing that in a > > fundamental way by establishing to the registering party a service route > > that it should be using when it makes calls. that part of the proposal > > breaks the sip protocol architecture and is thus unacceptable. > > Are you saying that it is in general unacceptable to use proxies to > provide > value-added services for outbound calls? I'd find that a hard position to > support, as one of the big advantages claimed for SIP has been its ability > to enable value-added services for both inbound and outbound calls. I give > some examples in another post on this topic. So it's just a question of > figuring out where to get those outbound services from . . . My basic statement is that users should always be able to get the basic services from their standard registration proxy, whatever their location in the network. They may want to get services from other proxies as well, but such services should be optional and the users' subscription should be explicit. In the basic configuration, we should assume that the communication between a UA and the registration proxy is encrypted. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 15:10:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24816 for ; Tue, 5 Mar 2002 15:10:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01667 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 15:10:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00140; Tue, 5 Mar 2002 14:46:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00107 for ; Tue, 5 Mar 2002 14:46:26 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23694 for ; Tue, 5 Mar 2002 14:46:23 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iKtD-0007BT-00; Tue, 05 Mar 2002 21:46:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.8334.995085.569677@harjus.eng.song.fi> Date: Tue, 5 Mar 2002 21:46:22 +0200 To: "Mark Watson" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > And indeed you can do this as I described in my earlier mail. There is > nothing to stop you establishing a data connection (PDP Context) with the > QoS that you want and sending your call over that, via whomever you want (if > your terminal supports it). sure, but does my home proxy the same capabilities to control the pdp context as the proxy of the mobile operator has for the 3gpp context? someone on this list mentioned earlier mentioned that that is not the case. in an open architecture, the operator 3gpp proxy would have no advantage over my home proxy for setting up the pdp contexts and controlling the calls. by the way, you didn't answer my question about why a 3gpp ua can't decide to make a 3gpp pdp context call directly from the visited network without using its home proxy. -- 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 daemon@optimus.ietf.org Tue Mar 5 19:41:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07872 for ; Tue, 5 Mar 2002 19:41:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19879 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 19:41:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18491; Tue, 5 Mar 2002 19:13:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA18462 for ; Tue, 5 Mar 2002 19:13:18 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07319 for ; Tue, 5 Mar 2002 19:13:16 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g260CBl03802; Tue, 5 Mar 2002 18:12:11 -0600 Message-ID: <021601c1c4a3$6fbc4f90$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: , "Mark Watson" Cc: References: <15493.8334.995085.569677@harjus.eng.song.fi> Subject: Re: [Sip] Path to Working Group Item Date: Tue, 5 Mar 2002 18:11:17 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > by the way, you didn't answer my question about why a 3gpp ua can't > decide to make a 3gpp pdp context call directly from the visited network > without using its home proxy. Because 3GPP provides value-added services in the home proxy. If you don't traverse the home proxy on mobile-originated calls, you don't get the value-added services. I gave an example earlier in the day using speed-dialing as a value-added-service. Other services might include simultaneous search (I know Juha might be at home, or work, or on his mobile, so I want my proxy to fork to all three destinations), transcription services, personal assistants, in-network conferencing (do the mixing "over there", so I pay only once for air time), automatic update of my presence status (dean is now in a call), etc. You could probably make a call without any services, but it's kindof of uninteresting from a business perspective so we don't talk about it alot, and it's not worth replacing the circuit-switch network with an IP network for. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 21:12:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09817 for ; Tue, 5 Mar 2002 21:12:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA23714 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 21:12:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22367; Tue, 5 Mar 2002 20:43:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22342 for ; Tue, 5 Mar 2002 20:42:59 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09204 for ; Tue, 5 Mar 2002 20:42:56 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g261gST13448; Tue, 5 Mar 2002 17:42:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA09277; Tue, 5 Mar 2002 17:42:01 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA04266; Tue, 5 Mar 2002 17:42:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.29699.88648.465434@thomasm-u1.cisco.com> Date: Tue, 5 Mar 2002 17:42:27 -0800 (PST) To: Flemming Andreasen Cc: "George Foti (LMC)" , "'sip@ietf.org'" Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <3C84ED04.2940DD69@cisco.com> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > > So if an untrusted UAC included a Remote-Party-ID, and the proxy is able to > > *validate* that (via some means) and consequently set the screen to YES, it > > is then up to the proxy (i.e it is optional) if it wants to include yet > > another Remote-Party-ID or not. > > Yes. I don't understand: which one does the UAS choose if there are two RPID's? I have another question: suppose that the UAC puts an RPID into an SMIME body. What is the intended behavior of the proxy? The UAS? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 5 22:42:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14353 for ; Tue, 5 Mar 2002 22:42:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA28340 for sip-archive@odin.ietf.org; Tue, 5 Mar 2002 22:42:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25633; Tue, 5 Mar 2002 21:54:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25602 for ; Tue, 5 Mar 2002 21:54:50 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11720 for ; Tue, 5 Mar 2002 21:54:47 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g262sAl04584; Tue, 5 Mar 2002 20:54:11 -0600 Message-ID: <001701c1c4ba$2b6d5070$133fed0c@C1893415A> From: "Dean Willis" To: "Michael Thomas" , References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se><3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> Subject: Re: [Sip] Questions/Comments on privacy-04 draft Date: Tue, 5 Mar 2002 20:54:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael asks: > I don't understand: which one does the UAS choose > if there are two RPID's? All of them? It's not a singular proposition. There are identities asserted. I've got six different identities associated with my PGP key. What's the problem? > I have another question: suppose that the UAC puts > an RPID into an SMIME body. What is the > intended behavior of the proxy? The UAS? Ooh, that's a good one. That's why I wanted to know who it was that asserted the RPID. Even better, I like to be able to verify that assertion. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 01:41:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17666 for ; Wed, 6 Mar 2002 01:41:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA17387 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 01:41:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11448; Wed, 6 Mar 2002 01:10:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11392 for ; Wed, 6 Mar 2002 01:10:47 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17381 for ; Wed, 6 Mar 2002 01:10:45 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iUdQ-0007LT-00; Wed, 06 Mar 2002 08:10:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.45796.602010.377436@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 08:10:44 +0200 To: "Dean Willis" Cc: "Mark Watson" , Subject: Re: [Sip] Path to Working Group Item In-Reply-To: <021601c1c4a3$6fbc4f90$bb036e3f@TXDWILLIS2> References: <15493.8334.995085.569677@harjus.eng.song.fi> <021601c1c4a3$6fbc4f90$bb036e3f@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Because 3GPP provides value-added services in the home proxy. If you don't > traverse the home proxy on mobile-originated calls, you don't get the > value-added services. if i don't want to use any value added services from my home proxy, but just want to make a cheaper call by just using the generic services of the network that i'm visiting (like ordering a pizza from a shop next to my hotel), 3gpp should allow me to do it. also, 3gpp should allow me to make that call without registering with my home proxy, because i don't want myself to be reachable. if 3gpp doesn't allow me to do that, 3gpp architecture is something very different from sip architecture and it doesn't make sense to pollute ietf sip protocol specifications with 3gpp requirements. -- 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 daemon@optimus.ietf.org Wed Mar 6 02:45:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26649 for ; Wed, 6 Mar 2002 02:45:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19956 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 02:46:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18793; Wed, 6 Mar 2002 02:24:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18762 for ; Wed, 6 Mar 2002 02:24:00 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26341 for ; Wed, 6 Mar 2002 02:23:57 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g267NxZc024080 for ; Wed, 6 Mar 2002 08:23:59 +0100 (MET) Received: FROM esealnt444.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 08:23:58 2002 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 08:22:50 +0100 Message-ID: <1254192C94D3D411B8060008C7E6AEEB04FC750A@esealnt408> From: "Stephen Terrill (ERA)" To: "'jh@lohi.eng.song.fi'" , Dean Willis Cc: Mark Watson , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 08:23:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I am slightly confused with some of this thread. 3GPP does allow a user to request pure IP connectivity, the location of the point of presence for this is dependant upon the users operator and the established business relationships. From this perspective, nothing is prevented as with IP connectivity you can do what is possible with IP. For this approach, the user will pay the IP resources used and the connecivity offered by the operator the user is with. In addition to that, I don't see any of the service possibilities removed with the 3GPP application of the SIP protocol. It is possible that the user can initiate calls to local services without been reachable, in the same way that it is possible to be registered and a service provided says that you are not reachable, or the terminal deciedes you are not reachable. ..//Steve -----Original Message----- From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: Wednesday, March 06, 2002 7:11 AM To: Dean Willis Cc: Mark Watson; sip@ietf.org Subject: Re: [Sip] Path to Working Group Item Dean Willis writes: > Because 3GPP provides value-added services in the home proxy. If you don't > traverse the home proxy on mobile-originated calls, you don't get the > value-added services. if i don't want to use any value added services from my home proxy, but just want to make a cheaper call by just using the generic services of the network that i'm visiting (like ordering a pizza from a shop next to my hotel), 3gpp should allow me to do it. also, 3gpp should allow me to make that call without registering with my home proxy, because i don't want myself to be reachable. if 3gpp doesn't allow me to do that, 3gpp architecture is something very different from sip architecture and it doesn't make sense to pollute ietf sip protocol specifications with 3gpp requirements. -- 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 daemon@optimus.ietf.org Wed Mar 6 02:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26744 for ; Wed, 6 Mar 2002 02:53:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20181 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 02:53:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19453; Wed, 6 Mar 2002 02:32:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19424 for ; Wed, 6 Mar 2002 02:32:48 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26506 for ; Wed, 6 Mar 2002 02:32:45 -0500 (EST) Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g267Wkd22254; Wed, 6 Mar 2002 08:32:46 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g267Wjk24890; Wed, 6 Mar 2002 08:32:45 +0100 (MET) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g267WimQ017767; Wed, 6 Mar 2002 08:32:44 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: jundery@ubiquity.net Date: Wed, 6 Mar 2002 08:32:41 +0100 MIME-Version: 1.0 Subject: [Sip] Questions to draft-undery-sip-auth-00.txt Reply-to: steffen.fries@mchp.siemens.de CC: sip@ietf.org Message-ID: <3C85D429.18695.3D256C8@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi James, within the current bis draft, the Authentication-Info header may only be sent in 2xx responses. The SIP Digest Authentication draft does not state this limitation explicitly. Is the intension to provide the Authentication-Info for every response, not only 2xx. If not, what would be the reason? By including the Authentication-Info header in all responses, one could already provide protection against some denial of service attacks (despite tzhe fact, that the draft states that these types of attacks are not countered) Regards Steffen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 02:59:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26859 for ; Wed, 6 Mar 2002 02:59:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20414 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 02:59:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19504; Wed, 6 Mar 2002 02:34:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19477 for ; Wed, 6 Mar 2002 02:34:09 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26528 for ; Wed, 6 Mar 2002 02:34:06 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iVw5-0007Ml-00; Wed, 06 Mar 2002 09:34:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.50797.553615.736611@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 09:34:05 +0200 To: "Stephen Terrill (ERA)" Cc: Dean Willis , Mark Watson , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <1254192C94D3D411B8060008C7E6AEEB04FC750A@esealnt408> References: <1254192C94D3D411B8060008C7E6AEEB04FC750A@esealnt408> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Stephen Terrill (ERA) writes: > I am slightly confused with some of this thread. i have tried to ask about what options the user has, when he/she uses the 3gpp multimedia subsystem (or whatever the term is) pdp context, because my understanding has been that the requirements described in the 3gpp internet draft are derived from that context and are not generic 3g requirements. and it looks like that in the 3gpp mms context, the user doesn't have the same options that a sip user has, but MUST register itself and MUST route all calls via its home network. -- 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 daemon@optimus.ietf.org Wed Mar 6 04:51:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28712 for ; Wed, 6 Mar 2002 04:51:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26960 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 04:51:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25030; Wed, 6 Mar 2002 04:22:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24992 for ; Wed, 6 Mar 2002 04:22:13 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28200 for ; Wed, 6 Mar 2002 04:22:09 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 6 Mar 2002 09:22:28 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Questions to draft-undery-sip-auth-00.txt Date: Wed, 6 Mar 2002 09:25:04 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552C5@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Questions to draft-undery-sip-auth-00.txt Thread-Index: AcHE4Ypjjc78LvFlS2iGc998KuPMCgADFWPg From: "James Undery" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA24993 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@mchp.siemens.de] > within the current bis draft, the Authentication-Info header > may only be sent in 2xx responses. The SIP Digest > Authentication draft does not state this limitation explicitly. > Is the intension to provide the Authentication-Info for every > response, not only 2xx. If not, what would be the reason? I definitely envisaged it in other responses such as 3xxs and 6xxs, the only restriction I can see is it must be in response to a request containing an Authorization header for that realm. (You need to know the identity the UAC is claiming.) > By including the Authentication-Info header in all responses, > one could already provide protection against some denial of > service attacks (despite tzhe fact, that the draft states that > these types of attacks are not countered) Definitely, although I would add that it could provide an almost identical result with selective application. James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 05:02:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28850 for ; Wed, 6 Mar 2002 05:02:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA27740 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 05:02:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26245; Wed, 6 Mar 2002 04:37:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26217 for ; Wed, 6 Mar 2002 04:37:55 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28477 for ; Wed, 6 Mar 2002 04:37:50 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g269brZc026594 for ; Wed, 6 Mar 2002 10:37:53 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g269brof018869 for ; Wed, 6 Mar 2002 11:37:53 +0200 (EET) Message-ID: <3C85E3B2.A457272E@lmf.ericsson.se> Date: Wed, 06 Mar 2002 11:38:58 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] To tag question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A small issue on the To tag. Chapter 8.2.6.2 says: "If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present)." Q1: I guess this is not the case for a response to CANCEL METHOD, where the request didn't contain a To tag. Should it be mentioned in this chapter? Q2: I guess this is not the case for a response to BYE METHOD, where the request didn't contain a To tag. Should it be mentioned in this chapter? Q3: If an unknown method (eg "MYMETHOD") is received, without a To tag, does the UAS really have to insert a tag in the 501 response? The UAS will NEVER accept this method, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 06:25:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01466 for ; Wed, 6 Mar 2002 06:25:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02546 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 06:25:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00734; Wed, 6 Mar 2002 05:57:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00708 for ; Wed, 6 Mar 2002 05:57:07 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00436 for ; Wed, 6 Mar 2002 05:57:02 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g26AuYR08331 for ; Wed, 6 Mar 2002 05:56:35 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Mar 2002 10:56:34 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00481E072@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: sip@ietf.org Date: Wed, 6 Mar 2002 10:56:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question on manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In section 11, None of the examples shows the PRACK/200 following the INVITE/183 as a new offer/answer exchange, but I think this is allowed, am I right? If this is allowed, if the PRACK carries new offer without precondition, does this mean that the caller doesn't need precondition anymore and the callee can start ringing whenever it wants? If the PRACK carries new offer contain precondition in the SDP (mandary precondition is present), does this PRACK also needs the require:precondition header? I think the answer is yes. Am I right? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 06:50:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02779 for ; Wed, 6 Mar 2002 06:50:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA04222 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 06:50:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03118; Wed, 6 Mar 2002 06:30:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03085 for ; Wed, 6 Mar 2002 06:30:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01707; Wed, 6 Mar 2002 06:30:47 -0500 (EST) Message-Id: <200203061130.GAA01707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 06:30:46 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-events-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sip-events-05.txt Pages : 38 Date : 05-Mar-02 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-events-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-events-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-events-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305135359.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-events-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-events-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305135359.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 daemon@optimus.ietf.org Wed Mar 6 07:01:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03221 for ; Wed, 6 Mar 2002 07:01:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA04836 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 07:01:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03915; Wed, 6 Mar 2002 06:42:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03892 for ; Wed, 6 Mar 2002 06:42:52 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02357 for ; Wed, 6 Mar 2002 06:42:48 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iZok-0007Yw-00; Wed, 06 Mar 2002 13:42:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.182.391605.790601@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 13:42:46 +0200 To: Mayer Georg Cc: Dean Willis , Mark Watson , sip@ietf.org Subject: AW: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mayer Georg writes: Our aim was not to pollute any area of serious work and I am sorry if you got that impression - we are happy that SIP and SIPPING groups undertook and still undertake major efforts to enable also the specific 3GPP requirements. The 3GPP IMS uses SIP in a specific way, as a private network uses SIP in a different way, etc.. enabling specific 3gpp ims requirements in ietf sip specifications is fine as long as the requirements don't contradict with the sip protocol architecture. the path header proposal unfortunately does so and therefore there is no way it can accepted. you simply can't add the path header to sip without a major rewrite of the existing sip specifications (the rfc and the bis). -- 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 daemon@optimus.ietf.org Wed Mar 6 07:07:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03542 for ; Wed, 6 Mar 2002 07:07:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA05308 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 07:07:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02610; Wed, 6 Mar 2002 06:26:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02582 for ; Wed, 6 Mar 2002 06:26:32 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01487 for ; Wed, 6 Mar 2002 06:26:28 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA29189; Wed, 6 Mar 2002 12:26:25 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA12861; Wed, 6 Mar 2002 12:26:12 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 12:26:32 +0100 Message-ID: From: Mayer Georg To: "'jh@lohi.eng.song.fi'" , Dean Willis Cc: Mark Watson , sip@ietf.org Subject: AW: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 12:26:33 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA02583 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Juha et al, > if i don't want to use any value added services from my home > proxy, but > just want to make a cheaper call by just using the generic services of > the network that i'm visiting (like ordering a pizza from a > shop next to > my hotel), 3gpp should allow me to do it. also, 3gpp should > allow me to > make that call without registering with my home proxy, because i don't > want myself to be reachable. Nothing is impossible - everything is permitted. If you don't want to use the 3G value added services that's fine with 3G - you just set up your SIP call via pure UMTS Packet Switchted Domain (GPRS). Then you will find exactly the behaviour we all know and love from a pure IP-based solution. You do not even need to register here. The 3GPP IMS is only a part of the whole 3GPP architecture, it is based on the Packet Switched domain. If you want value added services you need to route through the IMS, i.e. to your home network - you have to register and then you can use SIP as shown in the 3G specs. As said above the Packet Switched domain can work independently of IMS and provides you IP access as you outlined it. That's it - everyhting is permitted - nothing is impossible. > if 3gpp doesn't allow me to do that, 3gpp architecture is > something very > different from sip architecture and it doesn't make sense to pollute > ietf sip protocol specifications with 3gpp requirements. Our aim was not to pollute any area of serious work and I am sorry if you got that impression - we are happy that SIP and SIPPING groups undertook and still undertake major efforts to enable also the specific 3GPP requirements. The 3GPP IMS uses SIP in a specific way, as a private network uses SIP in a different way, etc.. As you joined this discussion I am sure you followed the process of IETF / 3GPP team-work during the last months - so you for sure have seen that 3GPP IMS is now a completely IETF SIP based solution, adopting all brand-new changes from the SIP drafts. All that we need here is some addition that allows us to apply SIP for our specific service. Keep on signalling Georg _______________________________________________________ Georg Mayer - Siemens AG Information and Communication Mobile ICM N PG SP ST N 1 Hofmannstr. 51, 81359 Munich, Germany Fon: +49-89-722-33114 Fax: +49-89-722-62250 Mobile: +49-172-5371233 Email: georg.mayer@icn.siemens.de > -----Urspr�ngliche Nachricht----- > Von: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Gesendet: Mittwoch, 6. M�rz 2002 07:11 > An: Dean Willis > Cc: Mark Watson; sip@ietf.org > Betreff: Re: [Sip] Path to Working Group Item > > > Dean Willis writes: > > > Because 3GPP provides value-added services in the home > proxy. If you don't > > traverse the home proxy on mobile-originated calls, you > don't get the > > value-added services. > > if i don't want to use any value added services from my home > proxy, but > just want to make a cheaper call by just using the generic services of > the network that i'm visiting (like ordering a pizza from a > shop next to > my hotel), 3gpp should allow me to do it. also, 3gpp should > allow me to > make that call without registering with my home proxy, because i don't > want myself to be reachable. > > if 3gpp doesn't allow me to do that, 3gpp architecture is > something very > different from sip architecture and it doesn't make sense to pollute > ietf sip protocol specifications with 3gpp requirements. > > -- 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 daemon@optimus.ietf.org Wed Mar 6 07:39:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04583 for ; Wed, 6 Mar 2002 07:39:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06755 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 07:39:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05742; Wed, 6 Mar 2002 07:20:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05713 for ; Wed, 6 Mar 2002 07:20:16 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04039 for ; Wed, 6 Mar 2002 07:20:11 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16iaOy-0007Zk-00; Wed, 06 Mar 2002 14:20:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.2428.7535.479007@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 14:20:12 +0200 To: "Mark Watson" Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > The point is that if you want to have that connection between the SIP > service layer and the PDP Contexts you need the cooperation of equipment in > the mobile (visited) network. This is why the calls need to go via the proxy > in the visited network (& why we need Path). you don't need path header in order to get the call to the proxy of visited network. we have discussed this tens of times already. you only need to tell the visiting ua to use the proxy of the visited network as its outbound proxy and that can be done with dhcp. > The visited network has no billing relationship with the subscriber and so > cannot collect revenue directly from the subscriber. Therefore there must be > interaction with the home network and 3GPP have chosen, for the moment, to > do this for IMS by requiring all call signalling to be routed via the home > network. sure the visited network must interwork with the home network for billing purpose, but it is a huge overkill to require also sip registration and other requests to go there. radius, for example, has been used for years by isps both for authentication and accounting information exchange between isps. it looks to me that the 3gpp walled garden architecture was designed by mobile operators and/or equipment vendors and they never bothered to ask what might the requirements of the mobile users be. those are the people who at the end of the day are going to pay the bill for all this. -- 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 daemon@optimus.ietf.org Wed Mar 6 07:44:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04803 for ; Wed, 6 Mar 2002 07:44:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA07239 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 07:44:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05160; Wed, 6 Mar 2002 07:03:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05130 for ; Wed, 6 Mar 2002 07:03:17 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03354 for ; Wed, 6 Mar 2002 07:03:12 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g26C1a529437; Wed, 6 Mar 2002 12:01:36 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 12:02:06 -0000 Message-ID: From: "Mark Watson" To: jh@lohi.eng.song.fi Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 12:02:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C506.BD687620" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C506.BD687620 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 05 March 2002 19:46 > To: Watson, Mark [MDN05:EP10:EXCH] > Cc: Dean Willis; sip@ietf.org > Subject: RE: [Sip] Path to Working Group Item > > > Mark Watson writes: > > > And indeed you can do this as I described in my earlier > mail. There is > > nothing to stop you establishing a data connection (PDP > Context) with the > > QoS that you want and sending your call over that, via > whomever you want (if > > your terminal supports it). > > sure, but does my home proxy the same capabilities to control the pdp > context as the proxy of the mobile operator has for the 3gpp context? If you access your home proxy over a simple IP connection then of course not. This is what the IP Multimedia Subsystem does: if your home proxy provider connects in to the IMS of other operators, they will be able to do whatever the mobile operators can do. But the price is you need to support the extensions which enable this cooperation and these are what we are trying to standardise here. The point is that if you want to have that connection between the SIP service layer and the PDP Contexts you need the cooperation of equipment in the mobile (visited) network. This is why the calls need to go via the proxy in the visited network (& why we need Path). If you don't want that interaction you can connect direct to your home proxy. You seem to be asking for interaction between the SIP service and the packet access (PDP Context), but without cooperation of a SIP entity in the network providing the access - this sounds impossible to me. > someone on this list mentioned earlier mentioned that that is not the > case. in an open architecture, the operator 3gpp proxy would have no > advantage over my home proxy for setting up the pdp contexts and > controlling the calls. > > by the way, you didn't answer my question about why a 3gpp ua can't > decide to make a 3gpp pdp context call directly from the > visited network > without using its home proxy. > Obne reason is billing. The visited network has no billing relationship with the subscriber and so cannot collect revenue directly from the subscriber. Therefore there must be interaction with the home network and 3GPP have chosen, for the moment, to do this for IMS by requiring all call signalling to be routed via the home network. ...Mark > -- juha > > ------_=_NextPart_001_01C1C506.BD687620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Path to Working Group Item

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 05 March 2002 19:46
> To: Watson, Mark [MDN05:EP10:EXCH]
> Cc: Dean Willis; sip@ietf.org
> Subject: RE: [Sip] Path to Working Group = Item
>
>
> Mark Watson writes:
>
>  > And indeed you can do this as I = described in my earlier
> mail. There is
>  > nothing to stop you establishing a = data connection (PDP
> Context) with the
>  > QoS that you want and sending your = call over that, via
> whomever you want (if
>  > your terminal supports it).
>
> sure, but does my home proxy the same = capabilities to control the pdp
> context as the proxy of the mobile operator has = for the 3gpp context?

If you access your home proxy over a simple IP = connection then of course not. This is what the IP Multimedia Subsystem = does: if your home proxy provider connects in to the IMS of other = operators, they will be able to do whatever the mobile operators can = do. But the price is you need to support the extensions which enable = this cooperation and these are what we are trying to standardise = here.

The point is that if you want to have that connection = between the SIP service layer and the PDP Contexts you need the = cooperation of equipment in the mobile (visited) network. This is why = the calls need to go via the proxy in the visited network (& why we = need Path).

If you don't want that interaction you can connect = direct to your home proxy.

You seem to be asking for interaction between the SIP = service and the packet access (PDP Context), but without cooperation of = a SIP entity in the network providing the access - this sounds = impossible to me.

> someone on this list mentioned earlier mentioned = that that is not the
> case.  in an open architecture, the = operator 3gpp proxy would have no
> advantage over my home proxy for setting up the = pdp contexts and
> controlling the calls.
>
> by the way, you didn't answer my question about = why a 3gpp ua can't
> decide to make a 3gpp pdp context call directly = from the
> visited network
> without using its home proxy.
>

Obne reason is billing.

The visited network has no billing relationship with = the subscriber and so cannot collect revenue directly from the = subscriber. Therefore there must be interaction with the home network = and 3GPP have chosen, for the moment, to do this for IMS by requiring = all call signalling to be routed via the home network.

...Mark

> -- juha
>
>

------_=_NextPart_001_01C1C506.BD687620-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 09:29:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09725 for ; Wed, 6 Mar 2002 09:29:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13096 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 09:29:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12318; Wed, 6 Mar 2002 09:12:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12280 for ; Wed, 6 Mar 2002 09:12:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08846 for ; Wed, 6 Mar 2002 09:12:43 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g26ECB305060; Wed, 6 Mar 2002 06:12:11 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA05771; Wed, 6 Mar 2002 06:12:14 -0800 (PST) Message-ID: <3C8623AC.BC0E853F@cisco.com> Date: Wed, 06 Mar 2002 09:11:56 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "George Foti (LMC)" , "'sip@ietf.org'" Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Flemming Andreasen writes: > > > So if an untrusted UAC included a Remote-Party-ID, and the proxy is able to > > > *validate* that (via some means) and consequently set the screen to YES, it > > > is then up to the proxy (i.e it is optional) if it wants to include yet > > > another Remote-Party-ID or not. > > > > Yes. > > I don't understand: which one does the UAS choose > if there are two RPID's? That's a local UA decision. > I have another question: suppose that the UAC puts > an RPID into an SMIME body. What is the > intended behavior of the proxy? The UAS? The use of bodies is fundamentally incompatible with network asserted identity, since proxies are not allowed to modify bodies (shouldn't even look at them). This should probably be stated explicitly. Currently, the draft only specifies that end-to-end encrypted Remote-Party-Id's cannot be trusted. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 09:31:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09937 for ; Wed, 6 Mar 2002 09:31:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13687 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 09:31:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12366; Wed, 6 Mar 2002 09:13:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12333 for ; Wed, 6 Mar 2002 09:13:28 -0500 (EST) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08868 for ; Wed, 6 Mar 2002 09:13:24 -0500 (EST) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.11.6/8.11.6) with ESMTP id g26EDOd15604; Wed, 6 Mar 2002 15:13:25 +0100 (MET) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g26EDOp13424; Wed, 6 Mar 2002 15:13:24 +0100 (MET) Received: from mhpaba5c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id g26EDOmQ022632; Wed, 6 Mar 2002 15:13:24 +0100 (MET) From: "Steffen Fries" Organization: Siemens AG To: , "James Undery" Date: Wed, 6 Mar 2002 15:13:19 +0100 MIME-Version: 1.0 Subject: RE: [Sip] Questions to draft-undery-sip-auth-00.txt Reply-to: steffen.fries@mchp.siemens.de CC: Message-ID: <3C86320F.14969.54121D3@localhost> Priority: normal In-reply-to: <45730E094814E44488F789C1CDED27AEC552C5@GBNEWP0758M.eu.ubiquity.net> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT > > within the current bis draft, the Authentication-Info header > > may only be sent in 2xx responses. The SIP Digest > > Authentication draft does not state this limitation explicitly. > > Is the intension to provide the Authentication-Info for every > > response, not only 2xx. If not, what would be the reason? > > I definitely envisaged it in other responses such as 3xxs and 6xxs, the > only restriction I can see is it must be in response to a request > containing an Authorization header for that realm. (You need to know the > identity the UAC is claiming.) > > > By including the Authentication-Info header in all responses, > > one could already provide protection against some denial of > > service attacks (despite tzhe fact, that the draft states that > > these types of attacks are not countered) > > Definitely, although I would add that it could provide an almost > identical result with selective application. Okay, that is exactly, what I was hoping ;-) Steffen________________________________________________________ ___ Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@mchp.siemens.de ___________________________________________________________ This email was written on 100% recycled bytes! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 09:50:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10817 for ; Wed, 6 Mar 2002 09:50:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14717 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 09:50:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13043; Wed, 6 Mar 2002 09:28:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12998 for ; Wed, 6 Mar 2002 09:28:44 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09673 for ; Wed, 6 Mar 2002 09:28:35 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26ES8T18756; Wed, 6 Mar 2002 06:28:08 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA11000; Wed, 6 Mar 2002 06:28:07 -0800 (PST) Message-ID: <3C862765.2B40FB23@cisco.com> Date: Wed, 06 Mar 2002 09:27:50 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Dean Willis writes: > > Michael asks: > > > I don't understand: which one does the UAS choose > > > if there are two RPID's? > > > > All of them? It's not a singular proposition. There are identities asserted. > > I've got six different identities associated with my PGP key. What's the > > problem? > > Well, if a proxy isn't capable of scrubbing > previous RPID's, the UAS gets the choice of > > Remote-party-id: mat@cisco.com > Remote-party-id: elvis@graceland.com > > What could possibly be useful about mat@cisco.com > when it could chose The King? Seriously, if RPID > is good for anything, it's to inform a UAS (and > likely the user) who's calling as known by the > service provider. Since there might be multiple RPID's > the UAS has no way to determine which one the proxy > inserted. Without cryptographic identity or scrubbing, > I simply don't understand how this is in any > way enforceable. > There is a screening indicator to indicate which one(s) the proxy believe are valid. Normally, I would expect a single identity (per type), but if there are multiple valid identies, I don't see a problem with that. > > > > I have another question: suppose that the UAC puts > > > an RPID into an SMIME body. What is the > > > intended behavior of the proxy? The UAS? > > > > Ooh, that's a good one. That's why I wanted to know who it was that asserted > > the RPID. Even better, I like to be able to verify that assertion. > > Yes. Thus my protestations that we're solving > the wrong problem. :-( Well, I've been hearing these statements for the past 2+ years without seeing any solutions - time's up IMHO. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 10:40:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09732 for ; Wed, 6 Mar 2002 09:29:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13110 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 09:29:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12252; Wed, 6 Mar 2002 09:12:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12224 for ; Wed, 6 Mar 2002 09:12:12 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08836 for ; Wed, 6 Mar 2002 09:12:09 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26EBZT10022; Wed, 6 Mar 2002 06:11:35 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA16636; Wed, 6 Mar 2002 06:11:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA04563; Wed, 6 Mar 2002 06:11:35 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.9111.53500.76084@thomasm-u1.cisco.com> Date: Wed, 6 Mar 2002 06:11:35 -0800 (PST) To: "Dean Willis" Cc: "Michael Thomas" , Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <001701c1c4ba$2b6d5070$133fed0c@C1893415A> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Michael asks: > > I don't understand: which one does the UAS choose > > if there are two RPID's? > > All of them? It's not a singular proposition. There are identities asserted. > I've got six different identities associated with my PGP key. What's the > problem? Well, if a proxy isn't capable of scrubbing previous RPID's, the UAS gets the choice of Remote-party-id: mat@cisco.com Remote-party-id: elvis@graceland.com What could possibly be useful about mat@cisco.com when it could chose The King? Seriously, if RPID is good for anything, it's to inform a UAS (and likely the user) who's calling as known by the service provider. Since there might be multiple RPID's the UAS has no way to determine which one the proxy inserted. Without cryptographic identity or scrubbing, I simply don't understand how this is in any way enforceable. > > I have another question: suppose that the UAC puts > > an RPID into an SMIME body. What is the > > intended behavior of the proxy? The UAS? > > Ooh, that's a good one. That's why I wanted to know who it was that asserted > the RPID. Even better, I like to be able to verify that assertion. Yes. Thus my protestations that we're solving the wrong problem. :-( Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 10:58:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14382 for ; Wed, 6 Mar 2002 10:58:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18724 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 10:58:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16464; Wed, 6 Mar 2002 10:16:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16431 for ; Wed, 6 Mar 2002 10:16:37 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12389 for ; Wed, 6 Mar 2002 10:16:33 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26FG6T16401; Wed, 6 Mar 2002 07:16:06 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA17333; Wed, 6 Mar 2002 07:15:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04567; Wed, 6 Mar 2002 07:16:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.12980.946950.813481@thomasm-u1.cisco.com> Date: Wed, 6 Mar 2002 07:16:04 -0800 (PST) To: Flemming Andreasen Cc: Michael Thomas , Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <3C862765.2B40FB23@cisco.com> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > There is a screening indicator to indicate which one(s) the proxy believe are > valid. Normally, I would expect a single identity (per type), but if there are > multiple valid identies, I don't see a problem with that. I still don't understand. If the proxy cannot remove a RPID header, a malicious UAC can clearly clone an identical RPID, screen=yes and all. Since the draft only says that a proxy MAY reject the request, there's nothing which necessarily enforces misbehaving UAC's from sending "trustworthy" RPID's. IMO, either you make it normative that a proxy MUST reject a UA which inserts RPID, or explicitly state that a UA MAY add RPID. The meta-state in the current draft leaves UAS's with complete ambiguity as to which one is trustable. Another problem I see: what if I run an untrusted proxy at home? Note that the trust issue is as seen by the downstream service provider's proxy, not by my proxy. In that case, mine quite reasonably might add RPID. Yet across the trust boundary, the downstream proxy would like to assert its version of RPID. Here it seems unreasonable to reject the message since my proxy is doing a perfectly legitimate proxy function. This would yet again lead to several different RPID's where the UAS would have no clue which one was more trustworthy. What I think this boils down to is that prohibiting UA's from inserting RPID is somewhere between useless and dangerous. Without the ability to scrub those headers, the trusted proxies are either defenseless, or put in a position of rejecting perfectly reasonable messages from other proxies. Something needs to give here. Either you allow scrubbing, or you require cryptographic identity (or both). The current security of this draft is not adequate, and since a generalized approach to crypto has been vetoed, I think this entire issue needs to revisited. > > > > I have another question: suppose that the UAC puts > > > > an RPID into an SMIME body. What is the > > > > intended behavior of the proxy? The UAS? > > > > > > Ooh, that's a good one. That's why I wanted to know who it was that asserted > > > the RPID. Even better, I like to be able to verify that assertion. > > > > Yes. Thus my protestations that we're solving > > the wrong problem. :-( > > Well, I've been hearing these statements for the past 2+ years without seeing any > solutions - time's up IMHO. Uh, I sure hope you're not impling that I had anything to do with the decision making here. In any case, you didn't answer the original question. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 11:24:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15934 for ; Wed, 6 Mar 2002 11:24:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21324 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 11:24:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17906; Wed, 6 Mar 2002 10:41:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17876 for ; Wed, 6 Mar 2002 10:41:50 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13717 for ; Wed, 6 Mar 2002 10:41:45 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26Ff8T02521; Wed, 6 Mar 2002 07:41:15 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA09480; Wed, 6 Mar 2002 07:41:07 -0800 (PST) Message-ID: <3C863881.BD5A8C2A@cisco.com> Date: Wed, 06 Mar 2002 10:40:49 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Flemming Andreasen writes: > > There is a screening indicator to indicate which one(s) the proxy believe are > > valid. Normally, I would expect a single identity (per type), but if there are > > multiple valid identies, I don't see a problem with that. > > I still don't understand. If the proxy cannot > remove a RPID header, a malicious UAC can clearly > clone an identical RPID, screen=yes and all. Since > the draft only says that a proxy MAY reject the > request, there's nothing which necessarily enforces > misbehaving UAC's from sending "trustworthy" RPID's. The draft very clearly states in Section 7.5 that the proxy either sets the screen parameter to "no" or removes the Remote-Party-ID - what's the problem ? > > IMO, either you make it normative that a proxy MUST > reject a UA which inserts RPID, or explicitly state > that a UA MAY add RPID. The meta-state in the current > draft leaves UAS's with complete ambiguity as to which > one is trustable. Two problems here. First of all, the proxy may not know what the previous hop is. Secondly, trusted UAs do in fact include Remote-Party-Ids. As far ambiguity goes, the screen parameter is there to tell the UA if the Remote-Party-Id is trustworthy or not. > Another problem I see: what if I run an untrusted > proxy at home? Note that the trust issue is as seen by > the downstream service provider's proxy, not by > my proxy. In that case, mine quite reasonably might > add RPID. Yet across the trust boundary, the downstream > proxy would like to assert its version of RPID. Right, and since the draft deals with network asserted caller-id, the one your proxy added will be deemed untrustworthy by having screen=no, unless it could be verified. > Here > it seems unreasonable to reject the message since > my proxy is doing a perfectly legitimate proxy > function. This would yet again lead to several > different RPID's where the UAS would have no > clue which one was more trustworthy. It seems you have missed the screen parameter function. > What I think this boils down to is that > prohibiting UA's from inserting RPID is > somewhere between useless and dangerous. Nowhere in the draft does it say that a UA cannot insert a Remote-Party-Id (in fact, trusted UAs do as described in the draft). As far as useless and dangerous goes, I don't follow either of them. > Without the ability to scrub those headers, > the trusted proxies are either defenseless, > or put in a position of rejecting perfectly > reasonable messages from other proxies. > Something needs to give here. Either you > allow scrubbing, or you require cryptographic > identity (or both). I repeat: scrubbing and setting "screen=no" are both allowed. > The current security of > this draft is not adequate, and since a > generalized approach to crypto has been > vetoed, I think this entire issue needs to > revisited. We have been down this path countless times without any kind of resolution. I have no reason to believe that this will change anytime soon and hence see no reason to repeat this yet again. There has been ample opportunity to come up with something better, but nothing has emerged. There is an applicability statement and an architecture description that points out the scenarios and assumptions under which the mechanism is useful and where it is not. I don't see the big problem here. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 11:30:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16329 for ; Wed, 6 Mar 2002 11:30:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22001 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 11:30:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18621; Wed, 6 Mar 2002 10:56:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18592 for ; Wed, 6 Mar 2002 10:56:41 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14294 for ; Wed, 6 Mar 2002 10:56:36 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26FuoZ01124 for ; Wed, 6 Mar 2002 17:56:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Mar 2002 17:56:39 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 17:56:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 6 Mar 2002 17:56:38 +0200 Message-ID: Thread-Topic: Some bis-09 findings Thread-Index: AcHFJ3kwavC9ZjDdEdatYABQi80jQw== To: X-OriginalArrivalTime: 06 Mar 2002 15:56:38.0502 (UTC) FILETIME=[8000D860:01C1C527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA18593 Subject: [Sip] Some bis-09 findings Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi! In the following some findings in the bis-09 draft (all line numbers refer to pdf version): * lines 1464-1465: If no provisional response has been received, the CANCEL request MUST NOT be sent; I guess, this also applies even if a 100 Trying has been received. Should be clarified. * lines 2573-2576, A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. 1) Does this mean, that in general the R-URI cannot be changed by a proxy, unless the R-URI points to this proxy? 2) Does this mean, that in general no new Route headers can be pushed to the Route-stack by a proxy, unless the R-URI points to this proxy? I think, the "MUST NOT" should be "SHOULD NOT" or a "IT IS NOT RECOMMENDED". Should be clarified. * Furthermore I propose to add a definition for "target set" in section 6. Regards, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 11:41:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17024 for ; Wed, 6 Mar 2002 11:41:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22989 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 11:41:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19867; Wed, 6 Mar 2002 11:07:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19836 for ; Wed, 6 Mar 2002 11:07:07 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14785 for ; Wed, 6 Mar 2002 11:07:03 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g26G6Zd10014; Wed, 6 Mar 2002 08:06:35 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA18164; Wed, 6 Mar 2002 08:06:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04574; Wed, 6 Mar 2002 08:06:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.16009.712770.624526@thomasm-u1.cisco.com> Date: Wed, 6 Mar 2002 08:06:33 -0800 (PST) To: Flemming Andreasen Cc: Michael Thomas , Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <3C863881.BD5A8C2A@cisco.com> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > Michael Thomas wrote: > > > Flemming Andreasen writes: > > > There is a screening indicator to indicate which one(s) the proxy believe are > > > valid. Normally, I would expect a single identity (per type), but if there are > > > multiple valid identies, I don't see a problem with that. > > > > I still don't understand. If the proxy cannot > > remove a RPID header, a malicious UAC can clearly > > clone an identical RPID, screen=yes and all. Since > > the draft only says that a proxy MAY reject the > > request, there's nothing which necessarily enforces > > misbehaving UAC's from sending "trustworthy" RPID's. > > The draft very clearly states in Section 7.5 that the proxy either sets the screen > parameter to "no" or removes the Remote-Party-ID - what's the problem ? It seems I've been led astray by the discussion here which led me to believe that the scrubbing/rewriting parts of the draft had been removed, and the "final" decision on the calls that RPID couldn't be included by a UA. I guess I missed when that was reversed (again). So I guess I'm OK with this. Two comments though: in section 6.5, it repeatedly says that there should only be one screen= tag, but it doesn't explicitly say that the intended behavior is that it should be rewritten. This is somewhat confusing. Second, in section, 5.1 it says that screen=no should take precedence over screen=yes? Am I misreading this? Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 11:50:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17601 for ; Wed, 6 Mar 2002 11:50:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23574 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 11:50:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21863; Wed, 6 Mar 2002 11:29:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21832 for ; Wed, 6 Mar 2002 11:29:50 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16294 for ; Wed, 6 Mar 2002 11:29:45 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g26GTlB22564; Wed, 6 Mar 2002 17:29:47 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g26GTkof015795; Wed, 6 Mar 2002 18:29:46 +0200 (EET) Message-ID: <3C86444B.EF21F9C1@lmf.ericsson.se> Date: Wed, 06 Mar 2002 18:31:07 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bernhard.honeisen@nokia.com CC: sip@ietf.org Subject: Re: [Sip] Some bis-09 findings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bernhard, > In the following some findings in the bis-09 draft > (all line numbers refer to pdf version): > > * lines 1464-1465: If no provisional response has been received, the CANCEL request MUST > NOT be sent; > > I guess, this also applies even if a 100 Trying has been received. > Should be clarified. No. You ARE allowed to send a CANCEL if you have received a 100 Trying. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 12:07:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18755 for ; Wed, 6 Mar 2002 12:07:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26149 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:07:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20227; Wed, 6 Mar 2002 11:10:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20102 for ; Wed, 6 Mar 2002 11:09:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14998; Wed, 6 Mar 2002 11:09:53 -0500 (EST) Message-Id: <200203061609.LAA14998@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 11:09:52 -0500 Subject: [Sip] I-D ACTION:draft-yu-tel-url-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the 'tel' and 'fax' URLs to Support Number Portability and Freephone Service Author(s) : J. Yu Filename : draft-yu-tel-url-04.txt Pages : 12 Date : 05-Mar-02 This document proposes some extensions to the 'tel' and 'fax' Uniform Resource Locators (URLs) for supporting number portability (NP) and freephone service. Those proposed extensions allow the Session Initiation Protocol (SIP) to carry those URLs or to convert those URLs to the SIP URL so as to support NP and freephone service. The proposed extensions allow the SIP protocol to be used to derive the routing number for the ported geographical numbers, identify the freephone service provider/carrier or the Plain Old Telephone Service (POTS) number for a freephone number, and carry the NP- and freephone-related information in the SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-tel-url-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-yu-tel-url-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-yu-tel-url-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134451.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yu-tel-url-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-yu-tel-url-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134451.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 daemon@optimus.ietf.org Wed Mar 6 12:14:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19366 for ; Wed, 6 Mar 2002 12:14:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26720 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:14:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22540; Wed, 6 Mar 2002 11:33:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22511 for ; Wed, 6 Mar 2002 11:33:49 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16563 for ; Wed, 6 Mar 2002 11:33:44 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA02614; Wed, 6 Mar 2002 17:33:41 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA10844; Wed, 6 Mar 2002 17:33:33 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:33:52 +0100 Message-ID: From: Mayer Georg To: "'jh@lohi.eng.song.fi'" Cc: Dean Willis , Mark Watson , sip@ietf.org Subject: AW: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 17:33:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22512 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Juha, thanks for the answer. > enabling specific 3gpp ims requirements in ietf sip specifications is > fine as long as the requirements don't contradict with the > sip protocol architecture. the path header proposal unfortunately does so and > therefore there is no way it can accepted. you simply can't add the > path header to sip without a major rewrite of the existing sip > specifications (the rfc and the bis). I need to understand where you think this major break in architecture occurs. Look at the 3GPP UMTS architecture. There is the PS domain (packet switched) and WITHIN it is the IMS. If the user wants to have normal SIP services, without using all that fancy stuff that she can get from the home.net: fine! So no contradiction with SIP protocol architecture. You can do basic SIP with 3GPP - just take a client, start it and everything works. That will be so already in "older" releases, i.e. pre-IMS. Perfect. Can we agree that this is not a contradiction to SIP? If the user wants these special services then the registration is needed. I thought we had discussed this already before, in and after SLC and got the feeling that this is not regarded as a (major or any) break of the SIP protocol architecture. It is just using the modular concept of SIP messages - use REGISTER in order to register at the Registrar and the Registrar then can do some further interesting things (like finding application servers due to user profile ....). This is even necessary when the Path header does not exist. So do we have a break here? If yes ... W-h-y-? Look at the paragraph above - you always can do all the basic SIP stuff without having REGISTER mandatory for callees. And now we come to the Path header. The system learns the path from the user to the Registrar and back. There were comments some months ago that path would only "record" a partial route and this could not be put to the Route header of the initial INVITE. Then we got loose routing, which allowed proxies to add intermediate hops to the route (exactly what we needed). As I understood it this solved the problems that IETF SIP(PING) experts had with the Path header. So is this the break? Please help me to understand the major issue here - maybe we can then find a solution or a miss-interpretation. Thank you Georg _______________________________________________________ Georg Mayer - Siemens AG Information and Communication Mobile ICM N PG SP ST N 1 Hofmannstr. 51, 81359 Munich, Germany Fon: +49-89-722-33114 Fax: +49-89-722-62250 Mobile: +49-172-5371233 Email: georg.mayer@icn.siemens.de > -----Urspr�ngliche Nachricht----- > Von: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Gesendet: Mittwoch, 6. M�rz 2002 12:43 > An: Mayer Georg > Cc: Dean Willis; Mark Watson; sip@ietf.org > Betreff: AW: [Sip] Path to Working Group Item > > > Mayer Georg writes: > > Our aim was not to pollute any area of serious work and I am sorry if > you got that impression - we are happy that SIP and SIPPING groups > undertook and still undertake major efforts to enable also > the specific > 3GPP requirements. The 3GPP IMS uses SIP in a specific way, as a > private network uses SIP in a different way, etc.. > > enabling specific 3gpp ims requirements in ietf sip specifications is > fine as long as the requirements don't contradict with the > sip protocol > architecture. the path header proposal unfortunately does so and > therefore there is no way it can accepted. you simply can't add the > path header to sip without a major rewrite of the existing sip > specifications (the rfc and the bis). > > -- 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 daemon@optimus.ietf.org Wed Mar 6 12:20:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19874 for ; Wed, 6 Mar 2002 12:20:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27495 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:20:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22903; Wed, 6 Mar 2002 11:39:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22876 for ; Wed, 6 Mar 2002 11:39:05 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16859 for ; Wed, 6 Mar 2002 11:39:00 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g26GcT306369; Wed, 6 Mar 2002 08:38:29 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA19104; Wed, 6 Mar 2002 08:38:32 -0800 (PST) Message-ID: <3C8645F6.7E849A1A@cisco.com> Date: Wed, 06 Mar 2002 11:38:14 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> <15494.16009.712770.624526@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > Two comments though: in section 6.5, 7.5 I presume > it > repeatedly says that there should only be one > screen= tag, but it doesn't explicitly say that > the intended behavior is that it should be > rewritten. This is somewhat confusing. Right now it talks about the proxy adding one screen parameter and making sure this is the only one. You could talk about rewriting an existing one if it existed, but it doesn't seem to change anything from a functional point of view. > Second, > in section, 5.1 6.1 I presume > it says that screen=no should > take precedence over screen=yes? Am I misreading this? > No. The header definition essentially says, that if you see a Remote-Party-Id with more than one screen parameter, then you shouldn't treat it as an error, but just go with the "no" value if present. The behavior section on the other hand says, that you don't include more than one screen parameter - it's the "be liberal in what you accept" philosophy. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 12:32:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20702 for ; Wed, 6 Mar 2002 12:32:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28800 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:32:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26782; Wed, 6 Mar 2002 12:15:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26753 for ; Wed, 6 Mar 2002 12:15:38 -0500 (EST) Received: from mail.mediatrix.com (mail.mediatrix.com [66.129.134.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19406 for ; Wed, 6 Mar 2002 12:15:33 -0500 (EST) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Mar 2002 12:15:37 -0500 Message-ID: From: Alexandre Charest To: "'bernhard.honeisen@nokia.com'" Cc: sip@ietf.org Subject: RE: [Sip] Some bis-09 findings Date: Wed, 6 Mar 2002 12:15:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org CANCEL request are hop-by-hop too and since each hop MUST wait until it received a response before issuing the CANCEL there is no problem. Alexandre C. -----Original Message----- From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] Sent: March 6, 2002 12:10 PM To: christer.holmberg@lmf.ericsson.se Cc: sip@ietf.org Subject: RE: [Sip] Some bis-09 findings Christer, > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 06. March 2002 18:31 > To: Honeisen Bernhard (NET/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] Some bis-09 findings > > > > Hi Bernhard, > > > In the following some findings in the bis-09 draft > > (all line numbers refer to pdf version): > > > > * lines 1464-1465: If no provisional response has been > received, the CANCEL request MUST > > NOT be sent; > > > > I guess, this also applies even if a 100 Trying has been received. > > Should be clarified. > > No. You ARE allowed to send a CANCEL if you have received a > 100 Trying. Are you sure? In line 1471-72 there is an explanation, which indicates somehow differently. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. As "100 Trying" are sent hop-to-hop, thus the UA could only have received a 100 Trying from the first proxy, and the registrar server, which can be behind several proxies, might not have received the original REGISTER request. Or did I miss something? cheers, Bernie > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 12:44:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21522 for ; Wed, 6 Mar 2002 12:44:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29723 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:44:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26455; Wed, 6 Mar 2002 12:10:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26413 for ; Wed, 6 Mar 2002 12:10:13 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19000 for ; Wed, 6 Mar 2002 12:10:08 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26H9Z303863 for ; Wed, 6 Mar 2002 19:09:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 19:10:11 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 19:10:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Some bis-09 findings Date: Wed, 6 Mar 2002 19:10:11 +0200 Message-ID: Thread-Topic: [Sip] Some bis-09 findings Thread-Index: AcHFLCJ6L1rqcd1JRkyGBDzqi/khQgABIgcg To: Cc: X-OriginalArrivalTime: 06 Mar 2002 17:10:11.0351 (UTC) FILETIME=[C6442A70:01C1C531] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA26416 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Christer, > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 06. March 2002 18:31 > To: Honeisen Bernhard (NET/Helsinki) > Cc: sip@ietf.org > Subject: Re: [Sip] Some bis-09 findings > > > > Hi Bernhard, > > > In the following some findings in the bis-09 draft > > (all line numbers refer to pdf version): > > > > * lines 1464-1465: If no provisional response has been > received, the CANCEL request MUST > > NOT be sent; > > > > I guess, this also applies even if a 100 Trying has been received. > > Should be clarified. > > No. You ARE allowed to send a CANCEL if you have received a > 100 Trying. Are you sure? In line 1471-72 there is an explanation, which indicates somehow differently. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. As "100 Trying" are sent hop-to-hop, thus the UA could only have received a 100 Trying from the first proxy, and the registrar server, which can be behind several proxies, might not have received the original REGISTER request. Or did I miss something? cheers, Bernie > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 12:46:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21691 for ; Wed, 6 Mar 2002 12:46:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29772 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:46:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27962; Wed, 6 Mar 2002 12:26:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27926 for ; Wed, 6 Mar 2002 12:26:16 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20207 for ; Wed, 6 Mar 2002 12:26:10 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ifB3-0007eY-00; Wed, 06 Mar 2002 19:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.20785.600023.503393@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 19:26:09 +0200 To: Mayer Georg Cc: Dean Willis , Mark Watson , sip@ietf.org Subject: AW: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please help me to understand the major issue here - maybe we can then find a solution or a miss-interpretation. georg, i welcome you as a new member of the 3gpp ims tag team. i start get bored to repeat the same issues in each message, but i'll try once more. the major problem with the path header is that it breaks the currently defined semantics of the register message. in the rfc and in the bis, register message has been defined for establishing a binding in the location service and for no other purpose. according to the current sip specifications, you only need to send a register request if you want to be reached. if you only want to reach others, you don't need to send the register message. all that text of the rfc and bis would need to be changed if we would adopt the proposed path response as part of sip. also, the current rfc and bis tell how and to where the ua sends a non-invite request. also all that text would need to be changed to take into account the case where the ua has registered itself and received back a path (which current UAs would not even understand). but it is not just the question of changing the text. i don't want the sip protocol architecture to be changed in such a way that a user has to register in order to be able to send non-invite requests. the user must be able to know to where and how to send non-invite requests without the information it gets back from the register message. in other words, discovery of the route to the destination ua cannot be bundled to the registration process. we must have other means to accomplish it and the current ones have been specified in the rfc and in the bis and in the srv i-d. so my suggestion to you is that if a 3gpp ims ua really needs the path information before it can send a non-register request, you define the path header as a 3gpp proprietary header in your own documents. by the way, no one in your tag team has yet been able to provide a convincing reason why even a 3gpp ua ua would need the path information. as we know, the ua can always get its requests to its home proxy by using the outbound proxy of the visited network and optionally a loose source route to the home proxy that it can find from the dns. then the entry proxy of the home network can (based on local subscriber information) forward the request to whatever internal proxy is needed to handle it. the entry proxy, by the way, doesn't need to record route itself, which means that only the initial message of each dialog would need to go via it. so my second suggestion is that unless you can show some fundamental flaw in the above process, you stop crying after the path response on this mailing list. -- 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 daemon@optimus.ietf.org Wed Mar 6 12:47:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21726 for ; Wed, 6 Mar 2002 12:47:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29792 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:47:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25541; Wed, 6 Mar 2002 12:01:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25509 for ; Wed, 6 Mar 2002 12:01:56 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18417 for ; Wed, 6 Mar 2002 12:01:50 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g26H1Lh22169; Wed, 6 Mar 2002 09:01:22 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA19301; Wed, 6 Mar 2002 09:00:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04583; Wed, 6 Mar 2002 09:00:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.19272.739953.153785@thomasm-u1.cisco.com> Date: Wed, 6 Mar 2002 09:00:56 -0800 (PST) To: Flemming Andreasen Cc: Michael Thomas , Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <3C8645F6.7E849A1A@cisco.com> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> <15494.16009.712770.624526@thomasm-u1.cisco.com> <3C8645F6.7E849A1A@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > > repeatedly says that there should only be one > > screen= tag, but it doesn't explicitly say that > > the intended behavior is that it should be > > rewritten. This is somewhat confusing. > > Right now it talks about the proxy adding one screen parameter and making sure this is the > only one. You could talk about rewriting an existing one if it existed, but it doesn't > seem to change anything from a functional point of view. I'm only commenting that the current text is rather oblique about what to do if there is a screen parameter already, but it is wrong from the point of view of the examining proxy. If the intended behavior is to rewrite it alone, it would be helpful to state that in the same place it states that it needs to differentiate the cases. > > it says that screen=no should > > take precedence over screen=yes? Am I misreading this? > > > > No. The header definition essentially says, that if you see a Remote-Party-Id with more > than one screen parameter, then you shouldn't treat it as an error, but just go with the > "no" value if present. The behavior section on the other hand says, that you don't include > more than one screen parameter - it's the "be liberal in what you accept" philosophy. I think you're misunderstanding me. This section implies that a UA should prefer a screen=no RPID over a screen=yes RPID. That seems reversed to me. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 12:55:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22403 for ; Wed, 6 Mar 2002 12:55:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00526 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 12:55:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26916; Wed, 6 Mar 2002 12:17:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26891 for ; Wed, 6 Mar 2002 12:17:23 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19554 for ; Wed, 6 Mar 2002 12:17:18 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g26HGm303291 for ; Wed, 6 Mar 2002 09:16:48 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACO38270; Wed, 6 Mar 2002 09:16:50 -0800 (PST) Date: Wed, 6 Mar 2002 09:14:58 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Path header vs. pre-loaded route in Contact Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I think Juha is proposing something like this. I haven't spent enough time with loose-routing to figure it out on my own. Does anyone have a reason why this wouldn't work instead of using the Path header? UA needs to find a proxy in the visited domain: - DHCPv6 option for SIP servers or - DHCPv6 option for domain name and then use DNS SRV or NAPTR to find a suitable server (for example: nyc.visited.net) Then the UA adopts this (visited) server as its outbound proxy, and registers with the home network. It adds a pre-loaded loose-route (which points at the visited proxy) into its Contact. REGISTER sip:home.net SIP/2.0 To: From: Contact: Route: sip:nyc.visited.net;lr ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Alternatively the visited server could add the pre-loaded Route to the contact. (Since, it's really a B2BUA anyway ;-) Since all the 3GPP entities support loose-routing, it seems at first glance that this should work fine. When the home proxy looks up the Contact for user@home.net, it inserts a Route header and forwards the call on as if the top-most Route URI was the request-URI. You can still go through as many border proxies as you want, before you arrive at the visited network, which strips the Route header and forwards the request onward. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 13:02:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23017 for ; Wed, 6 Mar 2002 13:02:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01379 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:02:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28403; Wed, 6 Mar 2002 12:30:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28347 for ; Wed, 6 Mar 2002 12:30:23 -0500 (EST) Received: from zctfs063.nortelnetworks.com (h90s131a237n47.user.nortelnetworks.com [47.237.131.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20559 for ; Wed, 6 Mar 2002 12:30:18 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g26HTAB25049; Wed, 6 Mar 2002 18:29:10 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:29:10 -0000 Message-ID: From: "Mark Watson" To: jh@lohi.eng.song.fi, Mayer Georg Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 17:29:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C534.68684640" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C534.68684640 Content-Type: text/plain Juha, If I understand rightly, your 'architectural' objection is to the use of Register for something related to outbound service - the principle you would like upheld being that Registration is a function related only to inbound service. Right ? If so, I think you are way way too late - 3GGP use of Register does all sorts of things related to outbound service already: choice of Service CSCF (home proxy), setting up of registration state in S-CSCF & HSS (subscription database), authentication & determination of session keys, etc. etc. As Georg mentions in his other post, this was all discussed some time ago (I remember a long thread about authentication being done only at Registration with subsequent messages relying on the session keys obtained at registration). In the 3GPP IMS you cannot send any messages at all (except REGISTER) until you have registered. So, without revisiting this point (i.e. accepting that, in 3GGP at least, Register is not related only to inbound service), what is your objection to the Path proposal for discovery of the service route for outbound calls ? I see you arguing about the technical merits of different solutions to discovery of a service route for outbound calls (i.e. using DHCP & DNS), but this is surely a technical argument, not an architectural one, and there does not seem to be any consensus that DHCP & DNS can do the things that Path is proposed for. Regards...Mark > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: 06 March 2002 11:43 > To: Mayer Georg > Cc: Dean Willis; Watson, Mark [MDN05:EP10:EXCH]; sip@ietf.org > Subject: AW: [Sip] Path to Working Group Item > > > Mayer Georg writes: > > Our aim was not to pollute any area of serious work and I am sorry if > you got that impression - we are happy that SIP and SIPPING groups > undertook and still undertake major efforts to enable also > the specific > 3GPP requirements. The 3GPP IMS uses SIP in a specific way, as a > private network uses SIP in a different way, etc.. > > enabling specific 3gpp ims requirements in ietf sip specifications is > fine as long as the requirements don't contradict with the > sip protocol > architecture. the path header proposal unfortunately does so and > therefore there is no way it can accepted. you simply can't add the > path header to sip without a major rewrite of the existing sip > specifications (the rfc and the bis). > > -- 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 > ------_=_NextPart_001_01C1C534.68684640 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Path to Working Group Item

Juha,

If I understand rightly, your 'architectural' = objection is to the use of Register for something related to outbound = service - the principle you would like upheld being that Registration = is a function related only to inbound service. Right ?

If so, I think you are way way too late - 3GGP use of = Register does all sorts of things related to outbound service already: = choice of Service CSCF (home proxy), setting up of registration state = in S-CSCF & HSS (subscription database), authentication & = determination of session keys, etc. etc.

As Georg mentions in his other post, this was all = discussed some time ago (I remember a long thread about authentication = being done only at Registration with subsequent messages relying on the = session keys obtained at registration). In the 3GPP IMS you cannot send = any messages at all (except REGISTER) until you have = registered.

So, without revisiting this point (i.e. accepting = that, in 3GGP at least, Register is not related only to inbound = service), what is your objection to the Path proposal for discovery of = the service route for outbound calls ?

I see you arguing about the technical merits of = different solutions to discovery of a service route for outbound calls = (i.e. using DHCP & DNS), but this is surely a technical argument, = not an architectural one, and there does not seem to be any consensus = that DHCP & DNS can do the things that Path is proposed = for.

Regards...Mark



> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 06 March 2002 11:43
> To: Mayer Georg
> Cc: Dean Willis; Watson, Mark = [MDN05:EP10:EXCH]; sip@ietf.org
> Subject: AW: [Sip] Path to Working Group = Item
>
>
> Mayer Georg writes:
>
>  Our aim was not to pollute any area of = serious work and I am sorry if
>  you got that impression - we are happy = that SIP and SIPPING groups
>  undertook and still undertake major = efforts to enable also
> the specific
>  3GPP requirements. The 3GPP IMS uses SIP = in a specific way, as a
>  private network uses SIP in a different = way, etc..
>
> enabling specific 3gpp ims requirements in ietf = sip specifications is
> fine as long as the requirements don't = contradict with the
> sip protocol
> architecture.  the path header proposal = unfortunately does so and
> therefore there is no way it can = accepted.  you simply can't add the
> path header to sip without a major rewrite of = the existing sip
> specifications (the rfc and the bis).
>
> -- 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
>

------_=_NextPart_001_01C1C534.68684640-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 13:11:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23618 for ; Wed, 6 Mar 2002 13:11:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01948 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:11:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28986; Wed, 6 Mar 2002 12:33:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28960 for ; Wed, 6 Mar 2002 12:33:52 -0500 (EST) Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20798 for ; Wed, 6 Mar 2002 12:33:46 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g26HSg008099; Wed, 6 Mar 2002 17:28:42 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:29:10 -0000 Message-ID: From: "Mark Watson" To: Michael Thomas , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Questions/Comments on privacy-04 draft Date: Wed, 6 Mar 2002 17:29:03 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C534.68F73FD0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1C534.68F73FD0 Content-Type: text/plain > > Well, if a proxy isn't capable of scrubbing > previous RPID's, the UAS gets the choice of > > Remote-party-id: mat@cisco.com > Remote-party-id: elvis@graceland.com > > Assuming these assertions come from a trusted proxy with screen=yes this implies that Michael *is* Elvis. This is a pefectly meaningful assertion, though we might think that the proxy is a little misguided (or mayby not - Is there something you're not telling us, Michael ? :-). ...Mark ------_=_NextPart_001_01C1C534.68F73FD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Questions/Comments on privacy-04 draft

>
>    Well, if a proxy isn't = capable of scrubbing
>    previous RPID's, the UAS gets = the choice of
>  
>    Remote-party-id: = mat@cisco.com
>    Remote-party-id: = elvis@graceland.com  
>
>

Assuming these assertions come from a trusted proxy = with screen=3Dyes this implies that Michael *is* Elvis. This is a = pefectly meaningful assertion, though we might think that the proxy is = a little misguided (or mayby not - Is there something you're not = telling us, Michael ? :-).

...Mark

------_=_NextPart_001_01C1C534.68F73FD0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 13:12:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23657 for ; Wed, 6 Mar 2002 13:12:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01967 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:12:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29690; Wed, 6 Mar 2002 12:43:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29645 for ; Wed, 6 Mar 2002 12:43:48 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21459 for ; Wed, 6 Mar 2002 12:43:44 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [132.151.1.176]) with SMTP; 6 Mar 2002 17:44:03 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Path to Working Group Item Date: Wed, 6 Mar 2002 17:46:49 -0000 Message-ID: <45730E094814E44488F789C1CDED27AEC552C8@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Path to Working Group Item Thread-Index: AcHFNKDYeoBMcakHSyWyaIjsRX1WYAAAKVuQ From: "James Undery" To: , "Mayer Georg" Cc: "Dean Willis" , "Mark Watson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA29646 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Now I've discovered it's a tag team I thought I better join as I've always wanted a lycra costume and mask ;-). (more sensible) comment below. > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > the major problem with the path header is that it breaks the currently > defined semantics of the register message. in the rfc and in the bis, > register message has been defined for establishing a binding in the > location service and for no other purpose. according to the > current sip > specifications, you only need to send a register request if > you want to > be reached. if you only want to reach others, you don't need to send > the register message. all that text of the rfc and bis would > need to be > changed if we would adopt the proposed path response as part of sip. The semantics of REGISTER are so broken and incongruous to the rest of SIP this can't go anyway towards being an argument. A proper provisioning mechanism is what's required, and with the beauty of hindsight I guess most people would agree. James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 13:13:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23798 for ; Wed, 6 Mar 2002 13:13:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02122 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:13:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29897; Wed, 6 Mar 2002 12:48:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29866 for ; Wed, 6 Mar 2002 12:48:30 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21836 for ; Wed, 6 Mar 2002 12:48:26 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ifWb-0007fQ-00; Wed, 06 Mar 2002 19:48:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.22121.803077.407472@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 19:48:25 +0200 To: "James Undery" Cc: "Mayer Georg" , "Dean Willis" , "Mark Watson" , Subject: RE: [Sip] Path to Working Group Item In-Reply-To: <45730E094814E44488F789C1CDED27AEC552C8@GBNEWP0758M.eu.ubiquity.net> References: <45730E094814E44488F789C1CDED27AEC552C8@GBNEWP0758M.eu.ubiquity.net> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery writes: > The semantics of REGISTER are so broken and incongruous to the rest of > SIP this can't go anyway towards being an argument. A proper > provisioning mechanism is what's required, and with the beauty of > hindsight I guess most people would agree. this is the first time i hear this kind of comment and very late in the bis process. i have almost two year expirience of running sip based services here and haven't found any major problems with the register request. -- 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 daemon@optimus.ietf.org Wed Mar 6 13:31:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25049 for ; Wed, 6 Mar 2002 13:31:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03317 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:31:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01428; Wed, 6 Mar 2002 13:03:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01397 for ; Wed, 6 Mar 2002 13:03:05 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23033 for ; Wed, 6 Mar 2002 13:03:01 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ifkk-0007fu-00; Wed, 06 Mar 2002 20:03:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.22998.712977.670236@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 20:03:02 +0200 To: Rohan Mahy Cc: sip@ietf.org Subject: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit looks like rohan's proposal to add the route parameter to the contact is an alternative to the new record-register-route header that i proposed. either way would solve the problem for routing incoming request to the ua via the proxy at the visited network. i suggest that we pick one and are done with this thread. -- 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 daemon@optimus.ietf.org Wed Mar 6 13:36:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25462 for ; Wed, 6 Mar 2002 13:36:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03835 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:36:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00140; Wed, 6 Mar 2002 12:50:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00099 for ; Wed, 6 Mar 2002 12:50:08 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21918 for ; Wed, 6 Mar 2002 12:50:04 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ifYE-0007fV-00; Wed, 06 Mar 2002 19:50:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.22221.952123.822592@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 19:50:05 +0200 To: "Mark Watson" Cc: Mayer Georg , Dean Willis , sip@ietf.org Subject: RE: [Sip] Path to Working Group Item In-Reply-To: References: X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > If I understand rightly, your 'architectural' objection is to the use of > Register for something related to outbound service - the principle you would > like upheld being that Registration is a function related only to inbound > service. Right ? yes, see the message that i sent a few minutes ago. i don't want have time to repeat it. > If so, I think you are way way too late - 3GGP use of Register does all > sorts of things related to outbound service already: choice of Service CSCF > (home proxy), setting up of registration state in S-CSCF & HSS (subscription > database), authentication & determination of session keys, etc. etc. that is fine. i have no intention to try to change how 3gpp ims operates. i send a few notes what i don't like about it, but i understand that you have long time ago decided on the walled garden architecture and will not open it up. what you decide in 3gpp ims, doesn't however have no implications on the ietf sip architecture. so please don't try to bring the walled garden model also to ietf. > So, without revisiting this point (i.e. accepting that, in 3GGP at least, > Register is not related only to inbound service), what is your objection to > the Path proposal for discovery of the service route for outbound calls ? as long as you don't try to change existing ietf sip protocol architecture and keep the path for yourself, i could not care less about it. > I see you arguing about the technical merits of different solutions to > discovery of a service route for outbound calls (i.e. using DHCP & DNS), but > this is surely a technical argument, not an architectural one, and there > does not seem to be any consensus that DHCP & DNS can do the things that > Path is proposed for. dhcp and srv records happen to be the ietf way of doing discovery. there is ietf consensus and working group documents about it. before that consensus is changed or augmented, it is your task to show what is wrong with procedure that i outlined in the previous message and that i have copied below. and even if we assume that you are able to find a real flaw in how i proposed to solve YOUR discovery problem with existing means, the fix is not to add anything to the register process, because as i have said soon thousand times, a sip user must be able to do the discovery without registration, which is only used in sip if someone want to receive inbound requests. -- juha ------------------------------------------ by the way, no one in your tag team has yet been able to provide a convincing reason why even a 3gpp ua ua would need the path information. as we know, the ua can always get its requests to its home proxy by using the outbound proxy of the visited network and optionally a loose source route to the home proxy that it can find from the dns. then the entry proxy of the home network can (based on local subscriber information) forward the request to whatever internal proxy is needed to handle it. the entry proxy, by the way, doesn't need to record route itself, which means that only the initial message of each dialog would need to go via it. so my second suggestion is that unless you can show some fundamental flaw in the above process, you stop crying after the path response on this mailing list. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 13:36:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25478 for ; Wed, 6 Mar 2002 13:36:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03864 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:36:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02179; Wed, 6 Mar 2002 13:14:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02147 for ; Wed, 6 Mar 2002 13:14:32 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23855 for ; Wed, 6 Mar 2002 13:14:28 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g26IE0h26488; Wed, 6 Mar 2002 10:14:00 -0800 (PST) Received: from oranlt ([161.44.238.50]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACE67818; Wed, 6 Mar 2002 10:14:09 -0800 (PST) From: "David R. Oran" To: , "'Rohan Mahy'" Cc: Subject: RE: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 13:13:49 -0500 Organization: Cisco Systems Message-ID: <03a601c1c53a$ab99c140$32ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <15494.22998.712977.670236@harjus.eng.song.fi> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Strikes me that Rohan's proposal is more flexible and general, since it can have any route the user wants for incoming calls as opposed to the inverse of the route that the Register took. If you actually want that behavior, though, how would you do the discovery? Do a record-route on a REGISTER and then re-register with what you want? Dave. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of jh@lohi.eng.song.fi > Sent: Wednesday, March 06, 2002 1:03 PM > To: Rohan Mahy > Cc: sip@ietf.org > Subject: [Sip] Path header vs. pre-loaded route in Contact > > > looks like rohan's proposal to add the route parameter to the > contact is an alternative to the new record-register-route > header that i proposed. either way would solve the problem > for routing incoming request to the ua via the proxy at the > visited network. i suggest that we pick one and are done > with this thread. > > -- 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 daemon@optimus.ietf.org Wed Mar 6 13:58:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27607 for ; Wed, 6 Mar 2002 13:58:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05917 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 13:58:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03812; Wed, 6 Mar 2002 13:35:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03780 for ; Wed, 6 Mar 2002 13:35:54 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25424 for ; Wed, 6 Mar 2002 13:35:50 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16igGV-0007gW-00; Wed, 06 Mar 2002 20:35:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.24967.715878.353826@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 20:35:51 +0200 To: "David R. Oran" Cc: "'Rohan Mahy'" , Subject: RE: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <03a601c1c53a$ab99c140$32ee2ca1@cisco.com> References: <15494.22998.712977.670236@harjus.eng.song.fi> <03a601c1c53a$ab99c140$32ee2ca1@cisco.com> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit David R. Oran writes: > If you actually want that behavior, though, how would you do the > discovery? Do a record-route on a REGISTER and then re-register with > what you want? this mechanism is only for register message in other to others to find a route to me. for outgoing non-requests, i would use the normal sip means, i.e., i would query dns for the proxy of the user i want to reach and then send the message there possibly via my outbound proxy (if any). -- 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 daemon@optimus.ietf.org Wed Mar 6 14:16:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28880 for ; Wed, 6 Mar 2002 14:16:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA07842 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 14:16:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04583; Wed, 6 Mar 2002 13:42:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04490 for ; Wed, 6 Mar 2002 13:42:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26289; Wed, 6 Mar 2002 13:42:36 -0500 (EST) Message-Id: <200203061842.NAA26289@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org, simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 13:42:36 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-message-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-sip-message-01.txt Pages : 22 Date : 05-Mar-02 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-message-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-message-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305135345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-message-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-message-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305135345.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 daemon@optimus.ietf.org Wed Mar 6 14:29:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00069 for ; Wed, 6 Mar 2002 14:29:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10212 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 14:29:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07082; Wed, 6 Mar 2002 14:06:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07051 for ; Wed, 6 Mar 2002 14:05:59 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28093 for ; Wed, 6 Mar 2002 14:05:55 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g26J5CS09390; Wed, 6 Mar 2002 13:05:12 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g26J5A403847; Wed, 6 Mar 2002 13:05:11 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g26J59E19847; Wed, 6 Mar 2002 14:05:09 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 14:05:39 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374DE@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 14:05:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, March 06, 2002 12:15 PM > To: sip@ietf.org > Subject: [Sip] Path header vs. pre-loaded route in Contact > > > Hi, > > I think Juha is proposing something like this. I haven't spent enough > time with loose-routing to figure it out on my own. Does > anyone have a > reason why this wouldn't work instead of using the Path header? > > UA needs to find a proxy in the visited domain: > > - DHCPv6 option for SIP servers > or > - DHCPv6 option for domain name and then use DNS SRV or NAPTR > to find a suitable server (for example: nyc.visited.net) > > Then the UA adopts this (visited) server as its outbound proxy, and > registers with the home network. It adds a pre-loaded loose-route > (which points at the visited proxy) into its Contact. > > REGISTER sip:home.net SIP/2.0 > To: > From: > Contact: > Route: sip:nyc.visited.net;lr ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Alternatively the visited server could add the pre-loaded Route to the > contact. (Since, it's really a B2BUA anyway ;-) The only way that the visited server can know the route to pre-load is through response coming back to it from the registration process in the PATH header, as the home proxy assigned to the subscriber takes place only at registration, and that proxy name is returned in the response ( as described previously) In conclusion the proposal cannot work > > Since all the 3GPP entities support loose-routing, it seems at first > glance that this should work fine. When the home proxy looks up the > Contact for user@home.net, it inserts a Route header and > forwards the call > on as if the top-most Route URI was the request-URI. You can still go > through as many border proxies as you want, before you arrive at the > visited network, which strips the Route header and forwards > the request > onward. > > thanks, > -rohan > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 14:49:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01402 for ; Wed, 6 Mar 2002 14:49:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12531 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 14:49:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07763; Wed, 6 Mar 2002 14:14:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07733 for ; Wed, 6 Mar 2002 14:14:40 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28805 for ; Wed, 6 Mar 2002 14:14:35 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g26JEbB17329 for ; Wed, 6 Mar 2002 20:14:37 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g26JEaof023116 for ; Wed, 6 Mar 2002 21:14:36 +0200 (EET) Message-ID: <3C866AEA.B38818D4@lmf.ericsson.se> Date: Wed, 06 Mar 2002 21:15:54 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SDP in unreliable 18x Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I am a little confused... Chapter 13.2.1 in bis-09 says: "If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." Now, does this mean I'm not allowed to send an SDP in an UN-reliable 18x? And, if I do, is it then not regardes as an answer? Eg the latest version of the isup draft uses unreliable (the PRACK has been removed completely from the draft) 18x messages, with SDP bodies (eg chapter 6.1.1. in draft-ietf-sipping-isup-01). They are needed for early media, remote ringback tones etc etc. But, according to bis they are not "valid" answers to the offer in INVITE. Have I missunderstood something? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 15:14:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02809 for ; Wed, 6 Mar 2002 15:14:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14733 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 15:14:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12151; Wed, 6 Mar 2002 14:45:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12054 for ; Wed, 6 Mar 2002 14:45:30 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01001 for ; Wed, 6 Mar 2002 14:44:40 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26JiCT15311; Wed, 6 Mar 2002 11:44:12 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA19029; Wed, 6 Mar 2002 11:44:11 -0800 (PST) Message-ID: <3C867179.B9A78671@cisco.com> Date: Wed, 06 Mar 2002 14:43:53 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> <15494.16009.712770.624526@thomasm-u1.cisco.com> <3C8645F6.7E849A1A@cisco.com> <15494.19272.739953.153785@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Flemming Andreasen writes: > > > repeatedly says that there should only be one > > > screen= tag, but it doesn't explicitly say that > > > the intended behavior is that it should be > > > rewritten. This is somewhat confusing. > > > > Right now it talks about the proxy adding one screen parameter and making sure this is the > > only one. You could talk about rewriting an existing one if it existed, but it doesn't > > seem to change anything from a functional point of view. > > I'm only commenting that the current text is > rather oblique about what to do if there is > a screen parameter already, but it is wrong > from the point of view of the examining proxy. > If the intended behavior is to rewrite it alone, > it would be helpful to state that in the same > place it states that it needs to differentiate > the cases. > OK > > > > it says that screen=no should > > > take precedence over screen=yes? Am I misreading this? > > > > > > > No. The header definition essentially says, that if you see a Remote-Party-Id with more > > than one screen parameter, then you shouldn't treat it as an error, but just go with the > > "no" value if present. The behavior section on the other hand says, that you don't include > > more than one screen parameter - it's the "be liberal in what you accept" philosophy. > > I think you're misunderstanding me. This section implies > that a UA should prefer a screen=no RPID over a > screen=yes RPID. That seems reversed to me. Not within a single Remote-Party-Id - if it both indicates that it is trustworthy ("yes") and non trustworthy ("no"), then I would say it's not trustworthy. If on the other hand there is one Remote-Party-Id that was screened ("yes") and one there was not ("no"), then I agree you'd be better off using the screened one, but that is not what the precedence is talking about. -- Flemming > > > Mike -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 15:14:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02824 for ; Wed, 6 Mar 2002 15:14:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14828 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 15:14:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12221; Wed, 6 Mar 2002 14:45:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12171 for ; Wed, 6 Mar 2002 14:45:46 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01050 for ; Wed, 6 Mar 2002 14:45:41 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g26Jinl10679; Wed, 6 Mar 2002 13:44:50 -0600 Message-ID: <013c01c1c547$3f24a2c0$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: "Rohan Mahy" , References: Subject: Re: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 13:43:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan wrote: > Does anyone have a > reason why this wouldn't work instead of using the Path header? > > UA needs to find a proxy in the visited domain: > > - DHCPv6 option for SIP servers > or > - DHCPv6 option for domain name and then use DNS SRV or NAPTR > to find a suitable server (for example: nyc.visited.net) > > Then the UA adopts this (visited) server as its outbound proxy, and > registers with the home network. It adds a pre-loaded loose-route > (which points at the visited proxy) into its Contact. > > REGISTER sip:home.net SIP/2.0 > To: > From: > Contact: > Route: sip:nyc.visited.net;lr ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Alternatively the visited server could add the pre-loaded Route to the > contact. (Since, it's really a B2BUA anyway ;-) This is a scaled-down version of my "compound contact" idea of about a year ago, which I think was my first response to the original Path proposal I heard from Bill Marshall. The approach as suggested only works if there is only one proxy, identity known to the roaming UA, in the path. If there are multiple proxies, for example firewall controllers, which may be unknown to the roaming UA at the time of registration, then it breaks. One could get around this by allowing intermediate proxies to edit the Contact, adding themselves to the compound-contact (I think I proposed something like this once). This is nicer than the synthesize-a-local-alias-and-remap-the-contact model, in that it doesn't require added state in the listed intermediate proxies, but it does have the same potential interaction with message integrity mechanisms that protect the Contact field. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 15:27:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03601 for ; Wed, 6 Mar 2002 15:27:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15397 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 15:27:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11684; Wed, 6 Mar 2002 14:40:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11653 for ; Wed, 6 Mar 2002 14:40:24 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00679 for ; Wed, 6 Mar 2002 14:40:19 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16ihGt-0007ir-00; Wed, 06 Mar 2002 21:40:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.28835.618132.536436@harjus.eng.song.fi> Date: Wed, 6 Mar 2002 21:40:19 +0200 To: "George Foti (LMC)" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C0374DE@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C0374DE@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > The only way that the visited server can know the route to pre-load is > through response coming back to it from the registration process in the PATH > header, as the home proxy assigned to the subscriber takes place only at > registration, and that proxy name is returned in the response ( as described > previously) > In conclusion the proposal cannot work george, you are spreading complete disinformation. either the ua or the visited proxy can find out the ip address of the home proxy of the visiting user by making a dns query for the sip srv record of the home domain of the visiting user. this has been mentioned at least a half of dozen times on this mailing list. i keep on copying the process until also you get it. -- juha ------------------------------------------------------------------- by the way, no one in your tag team has yet been able to provide a convincing reason why even a 3gpp ua ua would need the path information. as we know, the ua can always get its requests to its home proxy by using the outbound proxy of the visited network and optionally a loose source route to the home proxy that it can find from the dns. then the entry proxy of the home network can (based on local subscriber information) forward the request to whatever internal proxy is needed to handle it. the entry proxy, by the way, doesn't need to record route itself, which means that only the initial message of each dialog would need to go via it. so my second suggestion is that unless you can show some fundamental flaw in the above process, you stop crying after the path response on this mailing list. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 16:35:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07559 for ; Wed, 6 Mar 2002 16:35:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20891 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 16:35:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18853; Wed, 6 Mar 2002 16:13:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18818 for ; Wed, 6 Mar 2002 16:13:12 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06175 for ; Wed, 6 Mar 2002 16:13:08 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g26LCfT17845; Wed, 6 Mar 2002 13:12:41 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACO41999 (AUTH rmahy); Wed, 6 Mar 2002 13:12:39 -0800 (PST) Message-Id: <200203062112.ACO41999@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 6 Mar 2002 13:13:07 -0800 Date: Wed, 6 Mar 2002 13:13:07 -0800 From: Rohan Mahy Subject: Re: [Sip] Path header vs. pre-loaded route in Contact To: Dean Willis Cc: Rohan Mahy , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean said: >This is a scaled-down version of my "compound contact" idea of about a year >ago, which I think was my first response to the original Path proposal I >heard from Bill Marshall. > >The approach as suggested only works if there is only one proxy, identity >known to the roaming UA, in the path. If there are multiple proxies, for >example firewall controllers, which may be unknown to the roaming UA at the >time of registration, then it breaks. can we come up with other specific cases aside from 3GPP where this is likely to happen? I think your home proxy example was a good one, but only needs one pre-loaded route. also, I think you can get around this requirement in networks that control their own DNS, by using split DNS. The external DNS entries would point SRV records for the "inner" proxy at the "border" proxy, and the inside DNS would point at the inner proxy. can you think of any issues with this? >One could get around this by allowing intermediate proxies to edit the >Contact, adding themselves to the compound-contact (I think I proposed >something like this once). This is nicer than the >synthesize-a-local-alias-and-remap-the-contact model, in that it doesn't >require added state in the listed intermediate proxies, but it does have the >same potential interaction with message integrity mechanisms that protect >the Contact field. Yes. while I don't think this is a problem for 3GPP, we should keep the integrity issue in mind. thanks, -rohan > -- >Dean > > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 16:39:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07795 for ; Wed, 6 Mar 2002 16:39:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21023 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 16:39:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18367; Wed, 6 Mar 2002 16:06:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18336 for ; Wed, 6 Mar 2002 16:06:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05738 for ; Wed, 6 Mar 2002 16:06:37 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g26L69d23110; Wed, 6 Mar 2002 13:06:09 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACO41861 (AUTH rmahy); Wed, 6 Mar 2002 13:06:08 -0800 (PST) Message-Id: <200203062106.ACO41861@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 6 Mar 2002 13:06:36 -0800 Date: Wed, 6 Mar 2002 13:06:36 -0800 From: Rohan Mahy Subject: RE: [Sip] Path header vs. pre-loaded route in Contact To: George Foti (LMC) Cc: "'Rohan Mahy'" , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi George, I think you misunderstood me. ---- Original message ---- >Date: Wed, 6 Mar 2002 14:05:00 -0500 >From: "George Foti (LMC)" >Subject: RE: [Sip] Path header vs. pre-loaded route in Contact >To: "'Rohan Mahy'" , sip@ietf.org > >Comments inline >> -----Original Message----- >> From: Rohan Mahy [mailto:rohan@cisco.com] >> Sent: Wednesday, March 06, 2002 12:15 PM >> To: sip@ietf.org >> Subject: [Sip] Path header vs. pre-loaded route in Contact >> >> >> Hi, >> >> I think Juha is proposing something like this. I haven't spent enough >> time with loose-routing to figure it out on my own. Does >> anyone have a >> reason why this wouldn't work instead of using the Path header? >> >> UA needs to find a proxy in the visited domain: >> >> - DHCPv6 option for SIP servers >> or >> - DHCPv6 option for domain name and then use DNS SRV or NAPTR >> to find a suitable server (for example: nyc.visited.net) >> >> Then the UA adopts this (visited) server as its outbound proxy, and >> registers with the home network. It adds a pre-loaded loose-route >> (which points at the visited proxy) into its Contact. >> >> REGISTER sip:home.net SIP/2.0 >> To: >> From: >> Contact: >> Route: sip:nyc.visited.net;lr ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> Alternatively the visited server could add the pre-loaded Route to the >> contact. (Since, it's really a B2BUA anyway ;-) > >The only way that the visited server can know the route to pre-load is >through response coming back to it from the registration process in the PATH >header, as the home proxy assigned to the subscriber takes place only at >registration, and that proxy name is returned in the response ( as described >previously) >In conclusion the proposal cannot work George, this is a Route header in the Contact which gets used for incoming calls only. The visited proxy only needs to know its own address, or as Dean pointed out, any border proxies in the visited network that need to be in the path, but that wouldn't be reached if the home network was trying to use ordinary SIP loose-routing to get to nyc.visited.net The visited network doesn't need to know anything about proxies in the home network for example because loose-routing would cause them to be reached based on local policy in the home network. In the 3GPP case, it seems likely the P-CSCF would know the sip URI of any I-CSCF in the visited network, and could add this to the Contact header. Like Dean said, this could run afoul of end-to-end message integrity, but that's not likely to affect the 3GPP case. Can you think of anything else about this that would not work in the 3G case. thanks, -rohan > > >> >> Since all the 3GPP entities support loose-routing, it seems at first >> glance that this should work fine. When the home proxy looks up the >> Contact for user@home.net, it inserts a Route header and >> forwards the call >> on as if the top-most Route URI was the request-URI. You can still go >> through as many border proxies as you want, before you arrive at the >> visited network, which strips the Route header and forwards >> the request >> onward. >> >> thanks, >> -rohan >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 16:40:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07934 for ; Wed, 6 Mar 2002 16:40:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21085 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 16:40:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19271; Wed, 6 Mar 2002 16:19:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19152 for ; Wed, 6 Mar 2002 16:19:18 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06659 for ; Wed, 6 Mar 2002 16:19:13 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g26LIZS17067; Wed, 6 Mar 2002 15:18:35 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g26LIY407320; Wed, 6 Mar 2002 15:18:35 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g26LIYE27443; Wed, 6 Mar 2002 16:18:34 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 16:19:05 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Rohan Mahy'" Cc: sip@ietf.org Subject: RE: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 16:18:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Rohan, For incoming calls, that should work,. I am concerned about outgoing calls, which have to be handled by the home proxy of the originating sub. The request will get to the I-CSCF for the home, but after that, the I-CSCF has no way of routing it any further and it would have to interrogate a data base to find out the proxy assigned to the sub. for further routing. We would have to do that for every originating request, since the I-CSCF is stateless. Now that will lengthen the call set up time and is inefficient. By being able to return the proxy assigned to the mobile in a resgistration response, it can be pre-loaded by the P-CSCF for originating calls and we would save the step of I-CSCF interrogating the database for the proxy assigned to the sub. Dont know if that clarifies this case. Rgds/gf > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, March 06, 2002 4:07 PM > To: George Foti (LMC) > Cc: 'Rohan Mahy'; sip@ietf.org > Subject: RE: [Sip] Path header vs. pre-loaded route in Contact > > > Hi George, > > I think you misunderstood me. > > ---- Original message ---- > >Date: Wed, 6 Mar 2002 14:05:00 -0500 > >From: "George Foti (LMC)" > >Subject: RE: [Sip] Path header vs. pre-loaded route in > Contact > >To: "'Rohan Mahy'" , sip@ietf.org > > > >Comments inline > >> -----Original Message----- > >> From: Rohan Mahy [mailto:rohan@cisco.com] > >> Sent: Wednesday, March 06, 2002 12:15 PM > >> To: sip@ietf.org > >> Subject: [Sip] Path header vs. pre-loaded route in Contact > >> > >> > >> Hi, > >> > >> I think Juha is proposing something like this. I haven't > spent enough > >> time with loose-routing to figure it out on my own. Does > >> anyone have a > >> reason why this wouldn't work instead of using the Path > header? > >> > >> UA needs to find a proxy in the visited domain: > >> > >> - DHCPv6 option for SIP servers > >> or > >> - DHCPv6 option for domain name and then use DNS SRV or > NAPTR > >> to find a suitable server (for example: nyc.visited.net) > >> > >> Then the UA adopts this (visited) server as its outbound > proxy, and > >> registers with the home network. It adds a pre-loaded > loose-route > >> (which points at the visited proxy) into its Contact. > >> > >> REGISTER sip:home.net SIP/2.0 > >> To: > >> From: > >> Contact: Route=sip:nyc.visited.net;lr> > >> Route: sip:nyc.visited.net;lr > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> > >> > >> Alternatively the visited server could add the pre-loaded > Route to the > >> contact. (Since, it's really a B2BUA anyway ;-) > > > >The only way that the visited server can know the route to > pre-load is > >through response coming back to it from the registration > process in the PATH > >header, as the home proxy assigned to the subscriber takes > place only at > >registration, and that proxy name is returned in the > response ( as described > >previously) > >In conclusion the proposal cannot work > > George, this is a Route header in the Contact which gets used > for incoming calls only. The visited proxy only needs to > know its own address, or as Dean pointed out, any border > proxies in the visited network that need to be in the path, > but that wouldn't be reached if the home network was trying > to use ordinary SIP loose-routing to get to nyc.visited.net > > The visited network doesn't need to know anything about > proxies in the home network for example because loose-routing > would cause them to be reached based on local policy in the > home network. > > In the 3GPP case, it seems likely the P-CSCF would know the > sip URI of any I-CSCF in the visited network, and could add > this to the Contact header. Like Dean said, this could run > afoul of end-to-end message integrity, but that's not likely > to affect the 3GPP case. > > Can you think of anything else about this that would not work > in the 3G case. > > thanks, > -rohan > > > > > > > >> > >> Since all the 3GPP entities support loose-routing, it > seems at first > >> glance that this should work fine. When the home proxy > looks up the > >> Contact for user@home.net, it inserts a Route header and > >> forwards the call > >> on as if the top-most Route URI was the request-URI. You > can still go > >> through as many border proxies as you want, before you > arrive at the > >> visited network, which strips the Route header and > forwards > >> the request > >> onward. > >> > >> thanks, > >> -rohan > >> > >> > >> > >> _______________________________________________ > >> Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on > current sip > >> Use sipping@ietf.org for new developments on the > application of sip > >> > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on > current sip > >Use sipping@ietf.org for new developments on the application > of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 16:41:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08017 for ; Wed, 6 Mar 2002 16:41:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21124 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 16:41:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19146; Wed, 6 Mar 2002 16:19:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19116 for ; Wed, 6 Mar 2002 16:19:10 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06653 for ; Wed, 6 Mar 2002 16:19:06 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GSK00D01LUMWQ@firewall.wcom.com> for sip@ietf.org; Wed, 6 Mar 2002 21:18:23 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([166.38.62.54]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GSK00BJCLUGXP@firewall.wcom.com>; Wed, 06 Mar 2002 21:18:22 +0000 (GMT) Received: from pmismtp06.wcomnet.com by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSK00J01LUGC3@pmismtp06.wcomnet.com>; Wed, 06 Mar 2002 21:18:17 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSK00IH4LUCQU@pmismtp06.wcomnet.com>; Wed, 06 Mar 2002 21:18:16 +0000 (GMT) Date: Wed, 06 Mar 2002 15:18:17 -0600 From: Henry Sinnreich Subject: RE: [Sip] Path to Working Group Item In-reply-to: To: "'Mayer Georg'" , jh@lohi.eng.song.fi, "'Dean Willis'" Cc: "'Mark Watson'" , sip@ietf.org Message-id: <000701c1c554$71eda910$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA19117 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit To add to the fray I would like to take issue with the confusing term of "Packet Switched". Does "Packet Switched" mean Ethernet switching of some sorts, frame relay, X.25, ATM switching, SNA, IPX or IP routing? These "Packet Networks" are so much different, that the term becomes more than useless - it is misleading IMHO. If it is IP, call it IP. Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Mayer Georg > Sent: Wednesday, March 06, 2002 5:27 AM > To: 'jh@lohi.eng.song.fi'; Dean Willis > Cc: Mark Watson; sip@ietf.org > Subject: AW: [Sip] Path to Working Group Item > > > Hello Juha et al, > > > if i don't want to use any value added services from my home > > proxy, but > > just want to make a cheaper call by just using the generic > services of > > the network that i'm visiting (like ordering a pizza from a > > shop next to > > my hotel), 3gpp should allow me to do it. also, 3gpp should > > allow me to > > make that call without registering with my home proxy, > because i don't > > want myself to be reachable. > > Nothing is impossible - everything is permitted. > > If you don't want to use the 3G value added services that's > fine with 3G - you just set up your SIP call via pure UMTS > Packet Switchted Domain (GPRS). Then you will find exactly > the behaviour we all know and love from a pure IP-based > solution. You do not even need to register here. > > The 3GPP IMS is only a part of the whole 3GPP architecture, > it is based on the Packet Switched domain. If you want value > added services you need to route through the IMS, i.e. to > your home network - you have to register and then you can use > SIP as shown in the 3G specs. As said above the Packet > Switched domain can work independently of IMS and provides > you IP access as you outlined it. > > That's it - everyhting is permitted - nothing is impossible. > > > if 3gpp doesn't allow me to do that, 3gpp architecture is > > something very > > different from sip architecture and it doesn't make sense to pollute > > ietf sip protocol specifications with 3gpp requirements. > > Our aim was not to pollute any area of serious work and I am > sorry if you got that impression - we are happy that SIP and > SIPPING groups undertook and still undertake major efforts to > enable also the specific 3GPP requirements. The 3GPP IMS uses > SIP in a specific way, as a private network uses SIP in a > different way, etc.. As you joined this discussion I am sure > you followed the process of IETF / 3GPP team-work during the > last months - so you for sure have seen that 3GPP IMS is now > a completely IETF SIP based solution, adopting all brand-new > changes from the SIP drafts. All that we need here is some > addition that allows us to apply SIP for our specific service. > > Keep on signalling > Georg > _______________________________________________________ > Georg Mayer - Siemens AG > Information and Communication Mobile > ICM N PG SP ST N 1 > Hofmannstr. 51, 81359 Munich, Germany > Fon: +49-89-722-33114 > Fax: +49-89-722-62250 > Mobile: +49-172-5371233 > Email: georg.mayer@icn.siemens.de > > > > > > -----Urspr�ngliche Nachricht----- > > Von: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > > Gesendet: Mittwoch, 6. M�rz 2002 07:11 > > An: Dean Willis > > Cc: Mark Watson; sip@ietf.org > > Betreff: Re: [Sip] Path to Working Group Item > > > > > > Dean Willis writes: > > > > > Because 3GPP provides value-added services in the home > > proxy. If you don't > > > traverse the home proxy on mobile-originated calls, you > > don't get the > > > value-added services. > > > > if i don't want to use any value added services from my home > > proxy, but > > just want to make a cheaper call by just using the generic > services of > > the network that i'm visiting (like ordering a pizza from a > > shop next to > > my hotel), 3gpp should allow me to do it. also, 3gpp should > > allow me to > > make that call without registering with my home proxy, > because i don't > > want myself to be reachable. > > > > if 3gpp doesn't allow me to do that, 3gpp architecture is > > something very > > different from sip architecture and it doesn't make sense to pollute > > ietf sip protocol specifications with 3gpp requirements. > > > > -- juha > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 16:48:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08456 for ; Wed, 6 Mar 2002 16:48:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21514 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 16:48:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20101; Wed, 6 Mar 2002 16:30:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19937 for ; Wed, 6 Mar 2002 16:30:34 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07133 for ; Wed, 6 Mar 2002 16:28:50 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.05) id A47311C501D2; Wed, 06 Mar 2002 16:04:51 -0500 Message-ID: <010901c1c552$574f75e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , References: <3C866AEA.B38818D4@lmf.ericsson.se> Subject: Re: [Sip] SDP in unreliable 18x Date: Wed, 6 Mar 2002 16:03:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Christer Holmberg" > > Hi, > > I am a little confused... > > Chapter 13.2.1 in bis-09 says: > > "If the initial offer is in an INVITE, the answer MUST be in a > reliable non-failure message from UAS back to UAC which is > correlated to that INVITE. For this specification, that is > only the final 2xx response to that INVITE. That same exact > answer MAY also be placed in any provisional responses sent > prior to the answer. The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE." > > Now, does this mean I'm not allowed to send an SDP in an UN-reliable > 18x? And, if I do, is it then not regardes as an answer? You are allowed to send SDP in an unreliable 1xx. However, it MUST be the same as the SDP you will send in a 2xx. The key sentence is "That same exact answer MAY also be placed in any provisional responses sent prior to the answer." > > Eg the latest version of the isup draft uses unreliable (the PRACK has > been removed completely from the draft) 18x messages, with SDP bodies > (eg chapter 6.1.1. in draft-ietf-sipping-isup-01). They are needed for > early media, remote ringback tones etc etc. But, according to bis they > are not "valid" answers to the offer in INVITE. > > Have I missunderstood something? > > Regards, > > Christer Holmberg > Ericsson Finland > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 17:17:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10623 for ; Wed, 6 Mar 2002 17:17:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23490 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 17:17:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21391; Wed, 6 Mar 2002 16:45:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21360 for ; Wed, 6 Mar 2002 16:45:45 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08360 for ; Wed, 6 Mar 2002 16:45:41 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g26Lj6l11546; Wed, 6 Mar 2002 15:45:06 -0600 Message-ID: <02b001c1c558$0c3ad260$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: "George Foti \(LMC\)" , "'Rohan Mahy'" Cc: References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> Subject: Re: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 15:44:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George wrote: > I am concerned about outgoing calls, which have to be handled by the home > proxy of the originating sub. The request will get to the I-CSCF for the > home, but after that, the I-CSCF has no way of routing it any further and > it would have to interrogate a data base to find out the proxy assigned to > the sub. for further routing. > > We would have to do that for every originating request, since the I-CSCF is > stateless. Now that will lengthen the call set up time and is inefficient. > > By being able to return the proxy assigned to the mobile in a resgistration > response, it can be pre-loaded by the P-CSCF for originating calls and we > would save the step of I-CSCF interrogating the database for the proxy > assigned to the sub. One could use some other mechanism than REGISTER for discovering the dynamically assigned home proxy, and that mechanism could provide the entire home-side service route if needed. For example, a system I'm currently working with has the phone doing an HTTP GET for a configuration file that contains the name of the home-proxy cluster, and we send the phone a control message telling it to reload if there is a change. One could extend this to download a "Service route" that would include both the I-proxy and the S-proxy. This does use a couple more messages than REGISTER, so is by some measure less efficient, but it can be shown to work adequately. Whether one likes it or not, the REGISTER/PATH approach is reasonably efficient. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 17:19:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10796 for ; Wed, 6 Mar 2002 17:19:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23533 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 17:19:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22528; Wed, 6 Mar 2002 17:00:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22490 for ; Wed, 6 Mar 2002 17:00:43 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09161 for ; Wed, 6 Mar 2002 17:00:39 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g26Lxml11634; Wed, 6 Mar 2002 15:59:48 -0600 Message-ID: <02b601c1c55a$1a0f8dc0$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: "Rohan Mahy" Cc: "Rohan Mahy" , References: <200203062112.ACO41999@imop.cisco.com> Subject: Re: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 15:58:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan asked (referring to the need for more-than-one-hop service routes) > can we come up with other specific cases aside from 3GPP > where this is likely to happen? I think your home proxy > example was a good one, but only needs one pre-loaded route. Well, there might be one firewall proxy at my house, and another at my office, or some kind of multi-firewall transit network in between . . . Sure, we COULD play all sorts of games with DNS, but that does tend to get rather expensive as well as complicated to operate. but actually, I think you're solution works for one direction of the problem as it occurs in 3GPP. The roaming mobile discovers its adjacent proxy, and includes that proxy as part of a compound contact which it registers. This handles mobile-terminated calls. We have a seperate issue of how to discover service routes for mobile-originated calls, but (s pointed out by the asymetrric model of the Path draft), this is a seperable issue. Now, it may be worth pointing out that this "compound contact" approach appears to require fundamental changes to certain parts of the SIP grammar, and I can't see any off-hand way of making it backward compatible . . . > also, I think you can get around this requirement in networks > that control their own DNS, by using split DNS. The external > DNS entries would point SRV records for the "inner" proxy at > the "border" proxy, and the inside DNS would point at the > inner proxy. can you think of any issues with this? Yeah, split-DNS is a major source of defective network operation and generaly a bad stinking idea. It's probably required if you're running NAT, which is its own source of insanity, but probably not a good idea otherwise. It also tends to confuse the heck out of the border nodes, which I believe are the ones making the routing decision you're proposing. One has to build a three-layer model to handle the namespace issues, and that's expensive (50% more than a two-layer model). -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 18:07:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13874 for ; Wed, 6 Mar 2002 18:07:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26264 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 18:07:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24802; Wed, 6 Mar 2002 17:41:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24771 for ; Wed, 6 Mar 2002 17:41:32 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12357 for ; Wed, 6 Mar 2002 17:41:27 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g26MfRh21869; Wed, 6 Mar 2002 16:41:27 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g26MfQ426317; Wed, 6 Mar 2002 16:41:26 -0600 (CST) Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g26MfQE01763; Wed, 6 Mar 2002 17:41:26 -0500 (EST) Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:42:08 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C0374E7@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'Dean Willis'" , "George Foti (LMC)" , "'Rohan Mahy'" Cc: sip@ietf.org Subject: RE: [Sip] Path header vs. pre-loaded route in Contact Date: Wed, 6 Mar 2002 17:41:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean Willis wrote > > This does use a couple more messages than REGISTER, so is by > some measure > less efficient, but it can be shown to work adequately. > Whether one likes it > or not, the REGISTER/PATH approach is reasonably efficient. Absolutely so, and thats why it has been endorsed by 3GPP /gf > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 6 18:39:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15410 for ; Wed, 6 Mar 2002 18:39:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28150 for sip-archive@odin.ietf.org; Wed, 6 Mar 2002 18:40:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26708; Wed, 6 Mar 2002 18:18:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26679 for ; Wed, 6 Mar 2002 18:18:03 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14406 for ; Wed, 6 Mar 2002 18:17:58 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g26NHUS07359; Wed, 6 Mar 2002 17:17:31 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g26NHUb19984; Wed, 6 Mar 2002 17:17:30 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA25148; Wed, 6 Mar 2002 17:17:26 -0600 (CST) Message-ID: <3C86A3DE.4AD8B1E2@lmf.ericsson.se> Date: Thu, 07 Mar 2002 01:18:54 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: sip@ietf.org Subject: Re: [Sip] Question on manyfolks 05 References: <475FF955A05DD411980D00508B6D5FB00481E072@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello. "Chen, Xin (Xin)" wrote: > > In section 11, > > None of the examples shows the PRACK/200 following the INVITE/183 as a new > offer/answer exchange, but I think this is allowed, am I right? > The PRACK can carry an anwer. About a PRACK carrying an offer, it should not be done, because you would not have a way of refusing the offer without refusing the PRACK itself. > If this is allowed, if the PRACK carries new offer without precondition, > does this mean that the caller doesn't need precondition anymore and the > callee can start ringing whenever it wants? If at any time you send an offer without preconditions, the callee will be alerted. > > If the PRACK carries new offer contain precondition in the SDP (mandary > precondition is present), does this PRACK also needs the > require:precondition header? I think the answer is yes. Am I right? Yes. Gonzalo > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Thu Mar 7 00:26:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01704 for ; Thu, 7 Mar 2002 00:26:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA14759 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 00:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13057; Wed, 6 Mar 2002 23:55:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA13022 for ; Wed, 6 Mar 2002 23:55:14 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00651 for ; Wed, 6 Mar 2002 23:55:02 -0500 (EST) From: mgovind@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g274YKH18134 for ; Thu, 7 Mar 2002 10:04:20 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B75.001A09C7 ; Thu, 7 Mar 2002 10:14:24 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org Message-ID: <65256B75.001A0836.00@sampark.hss.hns.com> Date: Thu, 7 Mar 2002 10:14:20 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] draft-antti-rfc2806bis-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a doubt regarding the new syntax proposed for telurl . In the draft the grammar says telephone-uri = "tel:" subscriber subscriber = global-number / local-number global-number = "" 1*phonedigit [isdn-subaddress] *other local-number = 1*(phonedigit / HEXDIGIT ) [isdn-subaddress] context *other isdn-subaddress = ";isub=" 1*phonedigit context = ";context-tag=" 1*uric other = ";" oname "=" ovalue oname = 1*uric ovalue = *uric phonedigit = DIGIT / visual-separator visual-separator = "-" / "." / "(" / ")" If we see the syntax for "other " other = ";" oname "=" ovalue oname = 1*uric ovalue = *uric Here what is the significance of keeping an "=" as a must after oname , since ovalue is zero or more. Since it can be oname = . Instead of that why cant we keep other as other = oname | oname ["=" 1*uric]. If I am wrong please correct me. regards mahesh@hughes software systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 01:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02620 for ; Thu, 7 Mar 2002 01:11:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA23130 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 01:11:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15850; Thu, 7 Mar 2002 00:46:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15819 for ; Thu, 7 Mar 2002 00:46:47 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02084 for ; Thu, 7 Mar 2002 00:46:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g275khZc017625; Thu, 7 Mar 2002 06:46:43 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g275khof019343; Thu, 7 Mar 2002 07:46:43 +0200 (EET) Message-ID: <3C86FF05.80A3F331@lmf.ericsson.se> Date: Thu, 07 Mar 2002 07:47:49 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Penfield CC: sip@ietf.org Subject: Re: [Sip] SDP in unreliable 18x References: <3C866AEA.B38818D4@lmf.ericsson.se> <010901c1c552$574f75e0$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Bob, > >Now, does this mean I'm not allowed to send an SDP in an UN-reliable > >18x? And, if I do, is it then not regardes as an answer? > > You are allowed to send SDP in an unreliable 1xx. However, it MUST be the > same as the SDP you will send in a 2xx. The key sentence is "That same exact > answer MAY also be placed in any provisional responses sent prior to the > answer." True. But, in this case the UAC is not allowed to send a new offer (eg using UPDATE) before it has received the final response. Thanks for your answer! Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 02:10:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12170 for ; Thu, 7 Mar 2002 02:10:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00857 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 02:10:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29413; Thu, 7 Mar 2002 01:48:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29383 for ; Thu, 7 Mar 2002 01:48:02 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03595 for ; Thu, 7 Mar 2002 01:47:58 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16irh1-0007se-00; Thu, 07 Mar 2002 08:47:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.3359.485809.834546@harjus.eng.song.fi> Date: Thu, 7 Mar 2002 08:47:59 +0200 To: "Dean Willis" Cc: "George Foti \(LMC\)" , "'Rohan Mahy'" , Subject: Re: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <02b001c1c558$0c3ad260$bb036e3f@TXDWILLIS2> References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> <02b001c1c558$0c3ad260$bb036e3f@TXDWILLIS2> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > This does use a couple more messages than REGISTER, so is by some measure > less efficient, but it can be shown to work adequately. Whether one likes it > or not, the REGISTER/PATH approach is reasonably efficient. if you really want to pin down a proxy for the user (which as i have explained many times) is a bad idea, then you would need invent a new sip request for that purpose, because register message is not a general solution to the problem. the reason is that if i don't want to register at all and if for some very strange reason, i would still need the pinned down home proxy, i would have no way of getting it. but i haven't yet heard any convincing reason why such pining down of a home proxy would be needed. i start to suspect that the real reason is that the 3gpp ims folks have already decided to use the path message and can't change that decision. if that is the case, then do your own proprietary extension. -- 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 daemon@optimus.ietf.org Thu Mar 7 02:14:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12286 for ; Thu, 7 Mar 2002 02:14:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01044 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 02:14:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29164; Thu, 7 Mar 2002 01:42:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29133 for ; Thu, 7 Mar 2002 01:42:33 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03503 for ; Thu, 7 Mar 2002 01:42:30 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16irbj-0007sZ-00; Thu, 07 Mar 2002 08:42:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.3030.996329.314148@harjus.eng.song.fi> Date: Thu, 7 Mar 2002 08:42:30 +0200 To: "George Foti (LMC)" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> X-Mailer: VM 7.01 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George Foti (LMC) writes: > I am concerned about outgoing calls, which have to be handled by the home > proxy of the originating sub. The request will get to the I-CSCF for the > home, but after that, the I-CSCF has no way of routing it any further and > it would have to interrogate a data base to find out the proxy assigned to > the sub. for further routing. it is good that you now admit that your previous email about this topic was bogus and that in fact we don't need to do anything to the sip protocol in order to make the 3gpp ims service work. it is just a question of implementation efficiency and i simply don't believe that a single database query can be any issue at all. currently when my proxy gets an invite message, it needs to make lots of database queries, for example, to check if caller belongs to one of my home domains, if so, to check that the from address belongs to the user, to check that the user has the right to place a call to the to address, to check what long distance or international carrier the caller want to use, if it is emergency number, to check where the user is located, etc., etc. there are several possibilities to speed up the simple query that the 3gpp ims entry proxy needs to do. first is of course load balancing to keep the load of a single entry proxy low. then you could, for example, cash the next hop proxy in the memory of the entry proxy when the user registers and then make the query in a few milliseconds. i just bought 512 mb of ram for my computer and it costed me about usd 75. > We would have to do that for every originating request, since the I-CSCF is > stateless. Now that will lengthen the call set up time and is inefficient. see above. this is all bogus. > By being able to return the proxy assigned to the mobile in a resgistration > response, it can be pre-loaded by the P-CSCF for originating calls and we > would save the step of I-CSCF interrogating the database for the proxy > assigned to the sub. and what happens if the preloaded proxy dies? this kind of pinning down a particular proxy is a very bad idea in general. -- 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 daemon@optimus.ietf.org Thu Mar 7 03:23:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14113 for ; Thu, 7 Mar 2002 03:23:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA04971 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 03:23:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04341; Thu, 7 Mar 2002 03:08:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04317 for ; Thu, 7 Mar 2002 03:08:54 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13629 for ; Thu, 7 Mar 2002 03:08:50 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2788Jl15559; Thu, 7 Mar 2002 02:08:19 -0600 Message-ID: <002f01c1c5af$3722f0f0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "George Foti \(LMC\)" , "'Rohan Mahy'" , References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se><02b001c1c558$0c3ad260$bb036e3f@TXDWILLIS2> <15495.3359.485809.834546@harjus.eng.song.fi> Subject: Re: [Sip] Path header vs. pre-loaded route in Contact Date: Thu, 7 Mar 2002 02:08:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha said: > if you really want to pin down a proxy for the user (which as i have > explained many times) is a bad idea, then you would need invent a new > sip request for that purpose, because register message is not a general > solution to the problem. the reason is that if i don't want to register > at all and if for some very strange reason, i would still need the > pinned down home proxy, i would have no way of getting it. Actually, I think we have demonstrated that it's a reasonable solution to get this information from REGISTER as long as you're registering anyhow. There might be a requirement for another way to get it, if one wants to not register, but that's a seperate problem probably solvable a different way. > but i haven't yet heard any convincing reason why such pining down of a > home proxy would be needed. i start to suspect that the real reason is > that the 3gpp ims folks have already decided to use the path message and > can't change that decision. if that is the case, then do your own > proprietary extension. Then you aren't listening, because there have been ample reasons given to use a home service proxy, and I will want such an extension in my personal home phone so it's not just IMS. 1) We have rough consensus on providing an optional extension header to use REGISTER to discover service routes in each direction. I know, Juha disagrees, but that's the "rough part" . . . we can always consider other techniques for accomplishing similar goals. 2) We've had it proven that, even though it works like RecordRoute, we can't call this extension RecordRoute due to backward compatibility problems (as Jonathan Lennox reminded us), so Path's as good a name as any. 3) We have a draft on the table that provides baseline text for the extension. Somebody please volunteer to edit it the rest of the way home . . . 4) We've debated the heck out of it and haven't come up with an idea that's demonstrably cleaner, more efficient, or better enough to convince a quorum. So, unless somebody who's a) got a good argument otherwise, and b) isn't repeating Juha's argument, (because we've heard his argument, and while credible and argued with admirable tenacity, we have rough consensus to do otherwise) presents said argument to the contrary REALLY quickly, then I think we have to proceed with Path. So I strongly suggest we close this topic and get on with other work. Unless there is a striking new contribution, I plan to ignore any continuance of this thread, and request you all do the same. Good Day! -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 03:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14154 for ; Thu, 7 Mar 2002 03:24:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA05014 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 03:24:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03870; Thu, 7 Mar 2002 03:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03826 for ; Thu, 7 Mar 2002 03:02:22 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13532 for ; Thu, 7 Mar 2002 03:02:17 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g2782JB16793; Thu, 7 Mar 2002 09:02:19 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2782Iof027828; Thu, 7 Mar 2002 10:02:18 +0200 (EET) Message-ID: <3C871ECD.90972D08@lmf.ericsson.se> Date: Thu, 07 Mar 2002 10:03:25 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Chen, Xin (Xin)" , sip@ietf.org Subject: Re: [Sip] Question on manyfolks 05 References: <475FF955A05DD411980D00508B6D5FB00481E072@en0033exch001u.uk.lucent.com> <3C86A3DE.4AD8B1E2@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > >In section 11, > > > >None of the examples shows the PRACK/200 following the INVITE/183 as a new > >offer/answer exchange, but I think this is allowed, am I right? > > The PRACK can carry an anwer. About a PRACK carrying an offer, it should > not be done, because you would not have a way of refusing the offer > without refusing the PRACK itself. Chapter 5 in 100rel says: "If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK." "MAY" does not mean the same as "SHOULD NOT". Do we need a change in the text? However, IF the UAC receives a PRACK, with an offer it does NOT accept, what about sending a 2xx response to the PRACK, and a 415 response to the INVITE? Does it really matter if it refers to the session description in the INVITE, or in the PRACK, since the session setup has failed? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 04:42:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15405 for ; Thu, 7 Mar 2002 04:42:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA09742 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 04:42:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07976; Thu, 7 Mar 2002 04:14:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07942 for ; Thu, 7 Mar 2002 04:14:46 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15025 for ; Thu, 7 Mar 2002 04:14:42 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 7 Mar 2002 09:15:01 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Path to Working Group Item Date: Thu, 7 Mar 2002 09:17:49 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE012F82D7@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Path to Working Group Item Thread-Index: AcHFN5b+vclmI18QTIS4bORCaFB10QAgOlQg From: "James Undery" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA07943 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > James Undery writes: > > > The semantics of REGISTER are so broken and incongruous to > the rest of > > SIP this can't go anyway towards being an argument. A proper > > provisioning mechanism is what's required, and with the beauty of > > hindsight I guess most people would agree. > > this is the first time i hear this kind of comment and very > late in the > bis process. i have almost two year expirience of running sip based > services here and haven't found any major problems with the register > request. I'd check back over the SIP archive then ;-) As an implementor of registrars for over two years I have a problem with the fit of REGISTER into session initiation. James _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 05:31:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15984 for ; Thu, 7 Mar 2002 05:31:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA11892 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 05:31:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10074; Thu, 7 Mar 2002 04:55:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA10044 for ; Thu, 7 Mar 2002 04:54:58 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15574 for ; Thu, 7 Mar 2002 04:54:52 -0500 (EST) From: krisztian.kiss@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g279t5Z22686 for ; Thu, 7 Mar 2002 11:55:05 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Mar 2002 11:54:54 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 11:54:54 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 11:54:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Question on manyfolks 05 Date: Thu, 7 Mar 2002 11:54:52 +0200 Message-ID: Thread-Topic: [Sip] Question on manyfolks 05 Thread-Index: AcHFs6+9jbv0q4hHSqGliSdgj3EVywACDYuw To: , Cc: , X-OriginalArrivalTime: 07 Mar 2002 09:54:53.0764 (UTC) FILETIME=[21626840:01C1C5BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA10045 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, > -----Original Message----- > From: ext Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 07 March 2002 10:03 > To: Gonzalo Camarillo > Cc: Chen, Xin (Xin); sip@ietf.org > Subject: Re: [Sip] Question on manyfolks 05 > > > > Hi, > > > >In section 11, > > > > > >None of the examples shows the PRACK/200 following the > INVITE/183 as a new > > >offer/answer exchange, but I think this is allowed, am I right? > > > > The PRACK can carry an anwer. About a PRACK carrying an > offer, it should > > not be done, because you would not have a way of refusing the offer > > without refusing the PRACK itself. > > Chapter 5 in 100rel says: > > "If the UAC receives a reliable provisional response with an > answer, it MAY > generate an > additional offer in the PRACK. If the UAS receives a PRACK with an > offer, it MUST place the answer in the 2xx to the PRACK." > > "MAY" does not mean the same as "SHOULD NOT". Do we need a > change in the text? I guess Xin's original question concerned the case when the initial INVITE contains an offer + Require:precondition. When sending the PRACK, the precondition has not been met yet, so the question is whether it is allowed to send a new offer in PRACK with Require:precondition. BTW, can a reliable provisional response carry an offer and its PRACK the answer? Here is the scenario. Instead of this: <-------UPDATE (offer) -------->200 OK (answer) <-------180 -------->PRACK <--------200 OK this would be preferred: <-------180 (offer) -------->PRACK (answer) <--------200 OK Regards, Krisztian Kiss > However, IF the UAC receives a PRACK, with an offer it does > NOT accept, what > about sending a 2xx response to the PRACK, and a 415 response > to the INVITE? > Does it really matter if it refers to the session description > in the INVITE, or > in the PRACK, since the session setup has failed? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 07:20:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19631 for ; Thu, 7 Mar 2002 07:20:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18473 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 07:20:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17259; Thu, 7 Mar 2002 06:59:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17221 for ; Thu, 7 Mar 2002 06:59:23 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18578; Thu, 7 Mar 2002 06:59:19 -0500 (EST) Message-Id: <200203071159.GAA18578@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Mar 2002 06:59:19 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-call-auth-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 Extensions for Media Authorization Author(s) : W. Marshall et al. Filename : draft-ietf-sip-call-auth-04.txt Pages : 14 Date : 06-Mar-02 This document describes the need for QoS and media authorization and defines a SIP extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS belong to that administrative domain or federation of domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-call-auth-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-call-auth-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306144021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-auth-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-auth-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306144021.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 daemon@optimus.ietf.org Thu Mar 7 07:21:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19666 for ; Thu, 7 Mar 2002 07:21:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18503 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 07:21:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16499; Thu, 7 Mar 2002 06:46:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA16467 for ; Thu, 7 Mar 2002 06:46:10 -0500 (EST) Received: from localhost ([211.41.146.209]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17853 for ; Thu, 7 Mar 2002 06:46:03 -0500 (EST) Message-Id: <200203071146.GAA17853@ietf.org> Reply-To: donghakne@com.ne.kr From: 홍보팀 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 7 Mar 2002 20:45:17 +0900 Subject: [Sip] [광고] 10만원으로 600만이메일+발송기를 내품안에..^^; Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 홍보

 

 

위의 게임한판후에 아래내용을 천천히 읽어보세요...

       1. 메일 리스트보유량(600만)과 홍보방법
 
        ㄱ. 한메일,드림위즈,네이버,네띠앙,한미르,드림위즈,라이코스,세이클럽등 다량의 이메일리스트 보유
        ㄴ. 10만원으로 위의 이메일+발송기를 소유하시고 홍보를 하시거나...
        ㄷ. 또는 광고문구를 보내주시면 홍보를 주기적으로 대행을 해드립니다..

       2. 이메일마케팅이란?

        이메일마케팅이란 자신의 상품과 연관된 이메일 주소를 이메일 주소수집프로그램을 이용해 수집,
        편집프로그램을 이용해 가공해 발송프로그램을 이용해 발송하는 것입니다.

        기존의 대기업들은 수천만원에 수억원씩하는 CRM 시스템을 이용해 이메일마케팅을 했으며
        현재까지 나온 마케팅 방법중 가장 효과적인 방법입니다.

       3. 이메일마케팅으로 수익을 올릴 수 있냐구요?
 
        확실한 아이템(적정마진과 타켓을 고려)과 서버로그분석으로 충분한 수익을 올릴 수 있습니다.
 
        광고메일적용사례( Case study)
 
        ㄱ. 핸드폰 : 발송일수 2일 , 판매율 150대이상 잠재고객 유치 및 확보
        ㄴ. 커플링 : 발송일수 1일, 판매율 30링이상 잠재고객 유치 및 확보
        ㄷ. MP3 이벤트 프로모션 : 발송일수 2일 ,80대이상 잠재고객 유치 및 확보
        ㄹ. 침대가구 : 발송일수 5일 판매율 50대이상 , 잠재고객 유치 및 확보
        ㅁ. 성인방송: 발송일 회원유치 300명 ......등등

        관심또는 질문 있으신 분들은 메일주세요.... Email: donghakne@com.ne.kr
 
이후로는 메일이 발송되지 않습니다.?? ^^ [수신거부]

Copyright ⓒ1991-2002 Young Corporation. All rights reserved.

 

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 07:25:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19897 for ; Thu, 7 Mar 2002 07:25:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA18736 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 07:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17319; Thu, 7 Mar 2002 06:59:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17263 for ; Thu, 7 Mar 2002 06:59:28 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18590; Thu, 7 Mar 2002 06:59:23 -0500 (EST) Message-Id: <200203071159.GAA18590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Mar 2002 06:59:23 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-privacy-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks Author(s) : W. Marshall et al. Filename : draft-ietf-sip-privacy-04.txt Pages : 33 Date : 06-Mar-02 This document describes extensions to SIP that enable a network of trusted SIP servers to assert the identity of end users or end systems, and to convey indications of end-user requested privacy. The use of these extensions are only applicable inside an administrative domain, or among federations of administrative domains with previously agreed-upon policies for usage of such information. This document does NOT offer a general privacy or identity model suitable for inter-domain use or use in the Internet at large. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-privacy-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-privacy-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306144033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-privacy-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-privacy-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306144033.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 daemon@optimus.ietf.org Thu Mar 7 07:38:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20416 for ; Thu, 7 Mar 2002 07:38:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA19724 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 07:38:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17216; Thu, 7 Mar 2002 06:59:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17186 for ; Thu, 7 Mar 2002 06:59:18 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18565; Thu, 7 Mar 2002 06:59:14 -0500 (EST) Message-Id: <200203071159.GAA18565@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Mar 2002 06:59:14 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-dhcp-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : DHCP Option for SIP Servers Author(s) : H. Schulzrinne Filename : draft-ietf-sip-dhcp-06.txt Pages : 6 Date : 06-Mar-02 This document defines a DHCP-for-IPv4 option that contains a list of domain names or IPv4 addresses that can be mapped to one or more SIP outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-dhcp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-dhcp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020306144009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-dhcp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-dhcp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306144009.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 daemon@optimus.ietf.org Thu Mar 7 08:54:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24344 for ; Thu, 7 Mar 2002 08:54:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24076 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 08:54:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23279; Thu, 7 Mar 2002 08:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23223 for ; Thu, 7 Mar 2002 08:39:13 -0500 (EST) Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23430 for ; Thu, 7 Mar 2002 08:39:10 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d01.mx.aol.com (mail_out_v32.5.) id 7.8e.241c480c (4572); Thu, 7 Mar 2002 08:38:08 -0500 (EST) Message-ID: <8e.241c480c.29b8c73f@aol.com> Date: Thu, 7 Mar 2002 08:38:07 EST Subject: Re: [Sip] Comments on Resource Priority Header To: hgs@cs.columbia.edu CC: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 3/4/02 8:23:30 PM Eastern Standard Time, hgs@cs.columbia.edu writes: > > We don't have a lot of choice. It has to state what will happen to a call > > attempt if the priority value is not understood. A statement that it is > > treated as the lowest known value is about all that could be done. I don't > > see the value in defining a "default" other than the lowest. > > There are two choices: > > (1) If there's an unknown value, simply ignore the Resource-Priority > header. (Any unknown namespace will have to cause the RP header to be > ignored.) I point I think I was trying to make before is there can't be an "igonre" case. Since the point of the information is to tell equipment how to treat a call setup, in an environment/network that uses this capability, every call attempt must have a designated treatment, whether explicitly signaled, or a "default" when not present. An unknown value is equivalent to no value, which must default to something (unless the call attempt is rejected). Unknown namespace is another issue: I would expect the call to be rejected, since it is obviously someplace where it shouldn't be. > > (2) Treat unknown values as the lowest priority. > > The two are the same if and only if "no RP header = well-defined RP > value". I tend to think that that's a good general choice. I > intentionally say "well-defined", since it may not be the lowest value. > One could imagine a system where you can define a priority lower than a > normal, unadorned call. As a contrived example, imagine a gas meter > reader call, like the one my house gets around 10 pm each night, that > would label itself as "left-over". (As I mentioned, there is something > like that for IP QoS called scavenger service, or > worse-than-best-effort, which scrounges up the bandwidth crumbs left > over by BE traffic. Used for huge file transfers in Internet2.) > > From what I can tell, no such systems exist today, so this may be > academic. No, I don't think it is academic. It is worth considering. The result is that an added item would be needed in resource-priority to designate which level is the default for each namespace and to include the action it says above. I don't know that this would be a "well-defined" value. It would be different in each domain (namespace). For the dsn namespace, it would be "Routine"; for the q735 namespace, it would be "4". Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 09:33:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26522 for ; Thu, 7 Mar 2002 09:33:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26748 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 09:33:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25090; Thu, 7 Mar 2002 09:06:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25065 for ; Thu, 7 Mar 2002 09:06:57 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24988 for ; Thu, 7 Mar 2002 09:06:49 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA06970; Thu, 7 Mar 2002 09:06:48 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-43-237.mad.east.verizon.net [138.89.43.237]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g27E6kNB005341 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 7 Mar 2002 09:06:47 -0500 (EST) Message-ID: <3C8775AA.EB1D2E1@cs.columbia.edu> Date: Thu, 07 Mar 2002 09:14:02 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mgovind@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] draft-antti-rfc2806bis-02.txt References: <65256B75.001A0836.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Good point; it will be corrected in the next version. (The discussion of the draft belongs in IPTEL, not the SIP WG, btw.) mgovind@hss.hns.com wrote: > > Hi, > > I have a doubt regarding the new syntax proposed for telurl . > In the draft the grammar says > telephone-uri = "tel:" subscriber > subscriber = global-number / local-number > global-number = "" 1*phonedigit [isdn-subaddress] > *other > local-number = 1*(phonedigit / HEXDIGIT ) > [isdn-subaddress] > context *other > isdn-subaddress = ";isub=" 1*phonedigit > context = ";context-tag=" 1*uric > other = ";" oname "=" ovalue > oname = 1*uric > ovalue = *uric > phonedigit = DIGIT / visual-separator > visual-separator = "-" / "." / "(" / ")" > > If we see the syntax for "other " > > other = ";" oname "=" ovalue > oname = 1*uric > ovalue = *uric > > Here what is the significance of keeping an "=" as a must after oname , > since ovalue is zero or more. > Since it can be oname = . > > Instead of that why cant we keep other as other = oname | oname > ["=" 1*uric]. > If I am wrong please correct me. > > regards > mahesh@hughes software systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 09:35:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26675 for ; Thu, 7 Mar 2002 09:35:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26974 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 09:35:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25466; Thu, 7 Mar 2002 09:13:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25415 for ; Thu, 7 Mar 2002 09:13:22 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25484 for ; Thu, 7 Mar 2002 09:13:16 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g27ECm524775 for ; Thu, 7 Mar 2002 09:12:48 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 14:12:48 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00481E2D2@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Christer Holmberg , Gonzalo Camarillo Cc: "Chen, Xin (Xin)" , sip@ietf.org Subject: RE: [Sip] Question on manyfolks 05 Date: Thu, 7 Mar 2002 14:12:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer and Gonzalo, Thanks for your responses. I think the "MAY" in 100rel drafte is perfectly fine here. PRACK carries offer can be very useful. Becuase for example, to sovle the 1 of N codecs problem, I mean if the answer in 183 has multiple codecs for single media, then the PRACK can be used to narrow them to one, and it is not likely rejected by other peer. Even if it is rejected by 415, the UAC can learn the reason from 415 and try again. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: 07 March 2002 8:03 To: Gonzalo Camarillo Cc: Chen, Xin (Xin); sip@ietf.org Subject: Re: [Sip] Question on manyfolks 05 Hi, > >In section 11, > > > >None of the examples shows the PRACK/200 following the INVITE/183 as a new > >offer/answer exchange, but I think this is allowed, am I right? > > The PRACK can carry an anwer. About a PRACK carrying an offer, it should > not be done, because you would not have a way of refusing the offer > without refusing the PRACK itself. Chapter 5 in 100rel says: "If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK." "MAY" does not mean the same as "SHOULD NOT". Do we need a change in the text? However, IF the UAC receives a PRACK, with an offer it does NOT accept, what about sending a 2xx response to the PRACK, and a 415 response to the INVITE? Does it really matter if it refers to the session description in the INVITE, or in the PRACK, since the session setup has failed? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 10:03:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28450 for ; Thu, 7 Mar 2002 10:03:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29726 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 10:03:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27164; Thu, 7 Mar 2002 09:37:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27125 for ; Thu, 7 Mar 2002 09:37:09 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26795 for ; Thu, 7 Mar 2002 09:37:05 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 484154CE4E for ; Thu, 7 Mar 2002 09:37:09 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA09953; Thu, 7 Mar 2002 09:37:05 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA69344; Thu, 7 Mar 2002 09:37:03 -0500 (EST) Date: Thu, 7 Mar 2002 09:37:03 -0500 (EST) Message-Id: <200203071437.JAA69344@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Glare with PRACK vs. UPDATE. Was: Question on manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Krisztian Kiss wrote: > I guess Xin's original question concerned the case when the initial INVITE > contains an offer + Require:precondition. When sending the PRACK, the > precondition has not been met yet, so the question is whether it is allowed > to send a new offer in PRACK with Require:precondition. I believe this is allowed in the current offer/answe description. The original offer, in the INVITE, was answered in the provisional response. So at that point there is no offer pending, and either endpoint can send a new offer. The UAC can include the new offer in the PRACK message. However, this is an issue of glare here. Since there is no offer pending, the UAS can also send an updated offer in an UPDATE message. While UPDATE vs. UPDATE glare needs to be covered in the update draft, there is also a possibility of PRACK vs. UPDATE glare. In that case, I believe UPDATE should yield to PRACK in order to make the 100rel work. Can this case also be covered in the discussion of glare in the next revision of draft-ietf-sip-ipdate? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 10:19:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29532 for ; Thu, 7 Mar 2002 10:19:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01412 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 10:19:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28781; Thu, 7 Mar 2002 09:57:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28750 for ; Thu, 7 Mar 2002 09:57:08 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27992 for ; Thu, 7 Mar 2002 09:57:04 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 16izKJ-00089m-00; Thu, 07 Mar 2002 16:57:03 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.32703.821212.499226@lohi.eng.song.fi> Date: Thu, 7 Mar 2002 16:57:03 +0200 To: "Dean Willis" Cc: , "George Foti \(LMC\)" , "'Rohan Mahy'" Subject: Re: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <002f01c1c5af$3722f0f0$133fed0c@C1893415A> References: <32CD630F6CBED411AE180008C7894CBC0C0374E5@lmc37.lmc.ericsson.se> <02b001c1c558$0c3ad260$bb036e3f@TXDWILLIS2> <15495.3359.485809.834546@harjus.eng.song.fi> <002f01c1c5af$3722f0f0$133fed0c@C1893415A> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Then you aren't listening, because there have been ample reasons given to > use a home service proxy, and I will want such an extension in my personal > home phone so it's not just IMS. you send your invite to the proxy of your domain and that proxy can forward the invite to your personal proxy that handles the speed dial or whatever personal services you have. we can't have a function tht has nothing to do with registration and that only is available if someone registers. the same solution must be also available if someone doesn't want to register. finally, if you are going to push this through then please also edit the bis so that it is not inconsistent with your path. -- 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 daemon@optimus.ietf.org Thu Mar 7 10:39:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00954 for ; Thu, 7 Mar 2002 10:38:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03060 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 10:38:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00262; Thu, 7 Mar 2002 10:10:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00226 for ; Thu, 7 Mar 2002 10:10:16 -0500 (EST) Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28846 for ; Thu, 7 Mar 2002 10:10:12 -0500 (EST) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni02mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id KAA05591 for ; Thu, 7 Mar 2002 10:10:16 -0500 (EST) Message-ID: <09c501c1c5ea$2fc6a050$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: Date: Thu, 7 Mar 2002 10:10:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_09C2_01C1C5C0.46C5B7C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] Question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_09C2_01C1C5C0.46C5B7C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can someone please explain the differences between 100 & 183 = informational responses ? Why do we need these two ? Prabhas ------=_NextPart_000_09C2_01C1C5C0.46C5B7C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Can someone please explain the = differences between=20 100 & 183 informational responses ? Why do we need these two = ?
 
Prabhas
------=_NextPart_000_09C2_01C1C5C0.46C5B7C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 12:48:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10342 for ; Thu, 7 Mar 2002 12:48:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16607 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 12:48:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11933; Thu, 7 Mar 2002 11:58:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11888 for ; Thu, 7 Mar 2002 11:58:30 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06829 for ; Thu, 7 Mar 2002 11:58:24 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g27Gvlh00169; Thu, 7 Mar 2002 08:57:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABA44435; Thu, 7 Mar 2002 08:57:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04927; Thu, 7 Mar 2002 08:57:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15495.39946.633344.638185@thomasm-u1.cisco.com> Date: Thu, 7 Mar 2002 08:57:46 -0800 (PST) To: Flemming Andreasen Cc: Michael Thomas , Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft In-Reply-To: <3C867179.B9A78671@cisco.com> References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> <15494.16009.712770.624526@thomasm-u1.cisco.com> <3C8645F6.7E849A1A@cisco.com> <15494.19272.739953.153785@thomasm-u1.cisco.com> <3C867179.B9A78671@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > Michael Thomas wrote: > > I think you're misunderstanding me. This section implies > > that a UA should prefer a screen=no RPID over a > > screen=yes RPID. That seems reversed to me. > > Not within a single Remote-Party-Id - if it both indicates that it is trustworthy ("yes") and non > trustworthy ("no"), then I would say it's not trustworthy. If on the other hand there is one > Remote-Party-Id that was screened ("yes") and one there was not ("no"), then I agree you'd be > better off using the screened one, but that is not what the precedence is talking about. OK, I'm now even more confused. It says that there aren't supposed to be multiple screen= tags though. As in, a compliant proxy shouldn't do that. If what you're saying is that if a UA receives a RPID with multiple screen= tags it should consider it untrusted, I agree but the text is not very clear here: it seems to saying that if you get multiple *RPID's* you should prefer screen=no, which I think we agree is not how it should be interpreted. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 14:56:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19323 for ; Thu, 7 Mar 2002 14:56:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25173 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 14:56:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22839; Thu, 7 Mar 2002 14:12:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22807 for ; Thu, 7 Mar 2002 14:12:05 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15945 for ; Thu, 7 Mar 2002 14:12:00 -0500 (EST) Received: (qmail 5326 invoked from network); 7 Mar 2002 19:14:11 -0000 Received: from softdnserror (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 7 Mar 2002 19:14:11 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id D8E8B22818 for ; Thu, 7 Mar 2002 14:10:20 -0500 (EST) Message-ID: <3C87BB52.2070007@stake.com> Date: Thu, 07 Mar 2002 19:11:14 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question about differentiation between Strict-Routing and Loose Routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Can some one please explain me the exact difference between Loose Routing and Strict Routing. Not the definition please :) Thanks -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 15:03:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19868 for ; Thu, 7 Mar 2002 15:03:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25719 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 15:03:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23004; Thu, 7 Mar 2002 14:16:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22974 for ; Thu, 7 Mar 2002 14:16:07 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16209 for ; Thu, 7 Mar 2002 14:16:02 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA10318; Thu, 7 Mar 2002 14:15:33 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15763; Thu, 7 Mar 2002 14:15:33 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Mar 2002 14:15:33 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CC0E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Ofir Arkin'" , sip@ietf.org Subject: RE: [Sip] Question about differentiation between Strict-Routing a nd Loose Routing Date: Thu, 7 Mar 2002 14:15:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Strict Routing exactly follows the route given Loose Routing goes through the route, but may have extra hops Brian > -----Original Message----- > From: Ofir Arkin [mailto:ofir@stake.com] > Sent: Thursday, March 07, 2002 2:11 PM > To: sip@ietf.org > Subject: [Sip] Question about differentiation between > Strict-Routing and > Loose Routing > > > Can some one please explain me the exact difference between Loose > Routing and Strict Routing. > > Not the definition please :) > > Thanks > -- > Ofir Arkin > Managing Security Architect > @stake, Limited. > http://www.atstake.com > email: > ofir@stake.com > Tel: > +44 (0) 207 495 7002 > Fax: > +44 (0) 207 495 7062 > Mobile: +44 (0) 779 630 8632 > > ----------------------------- > The information transmitted is intended only for the person > or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, re transmission, dissemination or > other use of, > or taking of any action in reliance upon, this information by > persons or > entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and delete the > material from any computer. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 15:20:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21051 for ; Thu, 7 Mar 2002 15:20:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26227 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 15:20:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23885; Thu, 7 Mar 2002 14:30:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23836 for ; Thu, 7 Mar 2002 14:30:20 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17310 for ; Thu, 7 Mar 2002 14:30:15 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g27JU9I00683; Thu, 7 Mar 2002 14:30:09 -0500 Message-Id: <200203071930.g27JU9I00683@minotaur.nge.isi.edu> To: jo@ipdialog.com, brian.rosen@marconi.com, dwillis@dynamicsoft.com, sip@ietf.org Reply-To: mankin@isi.edu Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Mar 2002 14:30:09 -0500 From: Allison Mankin Subject: [Sip] SIP Success Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org SIP chairs and working group, The IESG approved the set of five documents that were Last Called, and approved the request for Fast Track RFC numbering that will enable 3GPP to reference SIP bis. I'll write a separate note about the Fast Track. As Area Director, I want to express my admiration for your amazingly hard work, and the high quality (almost always) and energy level of your discussions. Especial admiration is due to your document editors for their skill and responsiveness. The IESG and the RFC Editor made a few requests for clarifying changes. When the specs are sent to the RFC-Editor in an hour or so, they will be accompanied by the following RFC-Editor notes, which go into the specs automatically (no new i-ds will appear). Allison --------- Here are the RFC Editor notes for SIP, with thanks in advance to the RFC Editor for the support for this. draft-ietf-sip-rfc2543bis-09.txt - 1. This is a note addition that responds to an Area Director review identifying a problem that cannot be resolved with existing specifications. Note that currently there does not exist an exact IETF definition of case-insensitivity applied to the whole ISO 10466 character set, thus implementations should avoid dependencies on non-ASCII case-matching rules (or lack thereof) until an IETF definition and specification exists. Please add the above paragraph in two places in draft-ietf-sip-rfc2543bis-09.txt, which are; Section 7.3.1 Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. [Add the note as a new paragraph starting after the quoted sentence] Section 19.1.4 o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise. [Add the note as a continuation of the quoted bullet] 2. In draft-ietf-sip-rfc2543bis-09.txt, Section 20.12 third paragraph "coding" should be "encoding". 3. draft-ietf-sip-srv-06.txt This is a clarifying change that removes an appearance of inconsistency between this document and the bis protocol document. It responds to an Area Director review. In draft-ietf-sip-srv-06.txt, make the following substitution: OLD: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. NEW: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST NOT be rooted in a different domains (that is, if the query is for 'example.com', the answer must not return a replacement field with a domain suffix other than 'example.com', such as '_sips._tcp.differentdomain.com'). Similarly, for SIPS queries the domain name in the SRV query and the domain name in the target in the SRV record MUST NOT be rooted in different domains. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. 4. draft-ietf-sip-100rel-06.txt Replace the whole abstract with the following one, per request by the RFC-Editor for a more informative abstract, suitable for stand-alone understanding. The Session Initiation Protocol (SIP) is a transactional request-response protocol for the initiation, management, and termination of sessions. SIP provides two types of responses to a request. Final responses, which are in the range of 200 to 699, complete the transaction, and are sent reliably by SIP. Provisional responses, also known as informational responses, precede the final response, and provide status or progress information to the requestor. SIP does not provide reliability for these responses end-to-end. However, many applications of SIP have arisen which require these messages to be sent reliably end-to-end. This specification defines an extension to SIP using a new request method, called PRACK, which can be used to guarantee reliability of provisional responses. 5. The RFC Editor requested expansion of the acronym SIP and SDP where they are used in the titles and abstracts and this was agreed to. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 16:00:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23959 for ; Thu, 7 Mar 2002 16:00:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA28801 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 16:00:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27369; Thu, 7 Mar 2002 15:36:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27297 for ; Thu, 7 Mar 2002 15:36:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22511; Thu, 7 Mar 2002 15:36:38 -0500 (EST) Message-Id: <200203072036.PAA22511@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , sip@ietf.org, mmusic@ietf.org From: The IESG Date: Thu, 07 Mar 2002 15:36:38 -0500 Subject: [Sip] Protocol Action: SIP: Session Initiation Protocol to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o SIP: Session Initiation Protocol o Reliability of Provisional Responses in SIP o SIP: Locating SIP Servers o SIP-Specific Event Notification o An Offer/Answer Model with SDP These documents are the product of the Session Initiation Protocol Working Group and the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Allison Mankin and Scott Bradner Technical Summary This set of documents obsoletes RFC 2543 in defining the Session Initiation Protocol (SIP). Working Group Summary The SIP Working Group conducted an extensive discussion of all changes developed from RFC 2543 to this document set. The MMUSIC and SIP Working Groups both did extensive review of An Offer-Answer Model with SDP, which was developed as a needed feature for SIP use of Session Description Protocol (SDP) bodies, but which the MMUSIC validated as an SDP semantic. There was largely very strong consensus for the documents, throughout exhaustive review managed by the editors, despite the large amount of material encompassed. Consensus was strong to add an Internet threat analysis for SIP use to the document. However, a vocal group of participants preferred to minimize security features in SIP in favor of design of configurations with trust ("walled garden" style). Eventually consensus was achieved on non-walled garden security, including mandatory-to-implement TLS support in proxies and servers, and elimination of Basic (plaintext passwords) from the long-standing SIP User Agent Client (UAC) HTTP Authentication design. A rougher consensus formed around the requirement for end-to-end security support. The specification defines optional-to-implement S/MIME providing end-to-end integrity and confidentiality for both SIP headers and bodies. After more opportunities for implementation, the IESG expects that the requirement level of the S/MIME support will be upgraded in a future update. Protocol Quality As noted, the documents were reviewed extensively. Allison Mankin reviewed them for the IESG, along with targeted reviewing by a number of the other Area Directors. Eric Rescorla provided detailed security review. The draft on Location of SIP Servers was first considered by the IESG in a stand-alone Last Call some time ago. This version was carefully reviewed for the IESG by a number of Area Directors, and also by Leslie Daigle and Michael Mealling. Notes to RFC Editor: 1. Please add the following text in two places in draft-ietf-sip-rfc2543bis-09.txt Note that currently there does not exist an exact IETF definition of case-insensitivity applied to the whole ISO 10466 character set, thus implementations should avoid dependencies on non-ASCII case-matching rules (or lack thereof) until an IETF definition and specification exists. 1. In Section 7.3.1, following the text below: Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. 2. In Section 19.1.4, as a continuation of the following bullet o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other defined otherwise. 2. In draft-ietf-sip-rfc2543bis-09.txt, Section 20.12, third paragraph, please change "coding" to "encoding". 3. In draft-ietf-sip-srv-06.txt, please make the following substitution: OLD: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. NEW: For NAPTR records with SIPS protocol fields, the domain name in the query and the domain name in the replacement field MUST NOT be rooted in a different domains (that is, if the query is for 'example.com', the answer must not return a replacement field with a domain suffix other than 'example.com', such as '_sips._tcp.differentdomain.com'). Similarly, for SIPS queries the domain name in the SRV query and the domain name in the target in the SRV record MUST NOT be rooted in different domains. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. 4. Please replace the Abstract section of draft-ietf-sip-100rel-06.txt with the following: The Session Initiation Protocol (SIP) is a transactional request-response protocol for the initiation, management, and termination of sessions. SIP provides two types of responses to a request. Final responses, which are in the range of 200 to 699, complete the transaction, and are sent reliably by SIP. Provisional responses, also known as informational responses, precede the final response, and provide status or progress information to the requestor. SIP does not provide reliability for these responses end-to-end. However, many applications of SIP have arisen which require these messages to be sent reliably end-to-end. This specification defines an extension to SIP using a new request method, called PRACK, which can be used to guarantee reliability of provisional responses. 5. The IESG agrees with the RFC Editor that the acronyms SIP and SDP should be expanded where they are used in the titles and abstracts. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 18:06:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01245 for ; Thu, 7 Mar 2002 18:06:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA05405 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 18:06:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03878; Thu, 7 Mar 2002 17:34:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03849 for ; Thu, 7 Mar 2002 17:34:20 -0500 (EST) Received: from localhost ([218.48.221.167]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29659 for ; Thu, 7 Mar 2002 17:34:12 -0500 (EST) Message-Id: <200203072234.RAA29659@ietf.org> Reply-To: csp119@dreamwiz.com From: 메일마케팅 To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 8 Mar 2002 07:35:07 +0900 Subject: [Sip] [광고] 이메일 홍보 마케팅에 관심있으신분만 보세요!!! 그렇지 않으면 버리세요. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 공개 사과문

공개 사과문

 우선 귀하의 메일로 허락없이 보내 드려 너무 죄송합니다.이 메일은 1회성 메일로 추후 발송하   지 않을 것이며,다시는 이러한 메일로 귀하의 메일 계정을 더럽히지 않을 것입니다. 죄송합니다.

권고문

     메일은 정보통신부 권고 사항에 의거 제목에 [광고]라 표시된 광고 메일입니다.
       더 이상 메일을 수신하고 싶지 않으시면 <수신 당연히 거부>를 클릭해 주십시오.

제목

 홍보/마케팅 자료/마케팅 대행서비스 - <구입 문의 신청> 하시면 자세한 사항을 회신 드립니다.)

참조

 제품특징


호환이 문제 :  걱정 없습니다!!! 한줄에  하나씩, 그리고 TXT로 저장. -아마 행복하실 겁니다.
다음 우표제 :  지속적인 마케팅 노하우로 한메일이 적당히 썩여 있습니다.
중복 메일여 :  안심하십시오. 중복메일이 철저 배척합니다. 수신거부에 대빵 편리합니다.
통합이 문제 :  편리하게 사용하시도록 똑같은 개수로(10.000개씩) 나누었습니다.
가격이 문제 :  2시간이면 바로 본전 뽑힙니다.걱정 하지 마세요.
                    어떤  프로그램과도 100% 호환 가능합니다.       ...등등의 장점이 있습니다.

 

 판매내용

1.메일 마케팅 자료 : 2500만개+발송프로그램 = 300.000원

2.메일 마케팅 자료 : 4500만개+발송프로그램 =500.000원

 대행 설명 및 판매 설명입니다.

 대행설명

 1) 이메일 마케팅에 필요한 효과적인 데이타와 툴을 저렴하게 제공합니다.
   -한 시간내로 사용 가능 하게 해 드립니다.

 2) 컴퓨터와 인터넷에 익숙치 않은 분들, 혹은 직접 마케팅을 하시기에 시간이 부족한
    분들을 위하여 '이메일 마케팅 대행 서비스'를 저렴한 가격에 제공합니다.
  -정보메일 60만통 6만원 입니다.

중소 쇼핑몰 혹은 중소 기업 사장님들은 마케팅 원년의 해로 삼으시기 바랍니다.

 e-마케팅


 당사는 마케팅에 대한 노하우를 지닌 전문가와 함께 다양한 솔류션을 가지고
 EC 호스팅이 아닌 개별 상거래 페이지를 무료로 제작을 하여 드립니다.개별
 도메인에 의한 독자적인 사업ITEM으로, 어느 누구나 할려는 의지만 있으면,  다양한 판매
 방법과 연결, 짧짤한 수익이 돌아 올 수 있도록 도와 드립니다.
 단, 개인 재산이 되는 도메인  등록  비용 및 필요한 호스팅비는 들어 가겠지요!

 인터넷 비즈니스로 승부수를 던져 보세요.
 인터넷 비즈니스란 인터넷 상에서 자신이 원하는 상품을 팔거나, 판매를 목적으로
 구입하는  것을통괄하여 말하며, 용어로는 b2c, c2c, 그리고 크게는 b2b, b2b2c등등이 
 있습니다. 이러한  마케팅의 개념이 기존 처럼 큰 상점을 가지고 많은 물량을 진열하는
 마케팅에서 가정이나  조그마한 사무실에서도 아이템과 상품민 있으면 가능한 것 이기
 때문에 무점포 판매, 무재고의  신 개념 판매 기법으로 각광을 받고 있지 않나 생각
 합니다. 이는 적은 비용으로도 가장 효과적으로 전시/광고 할 수  있는 장점 때문입니다.

 필수 준수사항은!
 준비사항은 컴퓨터와 프린터 전용선이며, 준비가 되지 않은 사람은 리스나 저희와 상담을
 하시면 됩니다, 그리고 당연히 메일리스트가 있어야 합니다. 마치 여러분이 편지를 쓸려면
 주소가  필요 하듯이 메일 리스트가 준비가 필수겠죠.(단 1회성입니다.)
 네티즌의 권익보호와 정통부 권고사항을 필히 지키야 하는 것도 필수 사항입니다.

 이를 위해서는
 수신거부  처리에 대한 엄격한 관리 체제가 되어 있어야 합니다.
-<수신 당연히 거부> 함 눌러 보세요.
캡숑입니다.-바로 거부 들어갑니다.내용을 넣으십시오 

<구입 신청 방법>


<구입 의뢰 신청>바로 연락 드립니다.그리고 구입두 가능합니다. 
-메일 주실때 연락처/성함/회사-기재 요망--한 시간 내로 사용 가능 하게 해 드립니다.

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 19:16:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04029 for ; Thu, 7 Mar 2002 19:16:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07973 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 19:16:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06584; Thu, 7 Mar 2002 18:35:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06557 for ; Thu, 7 Mar 2002 18:35:03 -0500 (EST) Received: from localhost.localdomain (12-237-23-245.client.attbi.com [12.237.23.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02550 for ; Thu, 7 Mar 2002 18:34:58 -0500 (EST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g27NYwF01337; Thu, 7 Mar 2002 17:34:59 -0600 Subject: RE: [Sip] Question about differentiation between Strict-Routing a nd Loose Routing From: Robert Sparks To: "Rosen, Brian" Cc: "'Ofir Arkin'" , sip@ietf.org In-Reply-To: <313680C9A886D511A06000204840E1CF57CC0E@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF57CC0E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Mar 2002 17:34:58 -0600 Message-Id: <1015544099.1286.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Strict routing (with more than zero intermediaries) attempts to carry information about the request target and the next hop to be reached in the Request-URI. Loose routing leaves the request target in the Request-URI and the next hop in the Route header. RjS On Thu, 2002-03-07 at 13:15, Rosen, Brian wrote: > Strict Routing exactly follows the route given > Loose Routing goes through the route, but may have extra hops > > Brian > > > -----Original Message----- > > From: Ofir Arkin [mailto:ofir@stake.com] > > Sent: Thursday, March 07, 2002 2:11 PM > > To: sip@ietf.org > > Subject: [Sip] Question about differentiation between > > Strict-Routing and > > Loose Routing > > > > > > Can some one please explain me the exact difference between Loose > > Routing and Strict Routing. > > > > Not the definition please :) > > > > Thanks > > -- > > Ofir Arkin > > Managing Security Architect > > @stake, Limited. > > http://www.atstake.com > > email: > > ofir@stake.com > > Tel: > > +44 (0) 207 495 7002 > > Fax: > > +44 (0) 207 495 7062 > > Mobile: +44 (0) 779 630 8632 > > > > ----------------------------- > > The information transmitted is intended only for the person > > or entity to > > which it is addressed and may contain confidential and/or privileged > > material. Any review, re transmission, dissemination or > > other use of, > > or taking of any action in reliance upon, this information by > > persons or > > entities other than the intended recipient is prohibited. If you > > received this in error, please contact the sender and delete the > > material from any computer. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 22:44:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12251 for ; Thu, 7 Mar 2002 22:44:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17812 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 22:44:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16178; Thu, 7 Mar 2002 22:02:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16151 for ; Thu, 7 Mar 2002 22:01:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09964 for ; Thu, 7 Mar 2002 22:01:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2832L6Y028975; Thu, 7 Mar 2002 22:02:22 -0500 (EST) Message-ID: <3C882984.969AFDB2@dynamicsoft.com> Date: Thu, 07 Mar 2002 22:01:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Bob Penfield , sip@ietf.org Subject: Re: [Sip] SDP in unreliable 18x References: <3C86FF05.80A3F331@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi Bob, > > > >Now, does this mean I'm not allowed to send an SDP in an UN-reliable > > >18x? And, if I do, is it then not regardes as an answer? > > > > You are allowed to send SDP in an unreliable 1xx. However, it MUST be > the > > same as the SDP you will send in a 2xx. The key sentence is "That same > exact > > answer MAY also be placed in any provisional responses sent prior to > the > > answer." > > True. But, in this case the UAC is not allowed to send a new offer (eg > using > UPDATE) before it has received the final response. Right. The idea was to try and add a semblance of compatibility with existing implementations. We want everything to be mapped to a set of non-overlapping O/A exchanges. So, the idea is that the SDP in an unrealiable 18x, and the SDP in a 2xx, are just the same answer. THus, we maintain the property of everything being a series of O/A exchanges, but allow a single answer to be present in multiple sip responses. However, it is NOT allowed, to send an offer in INVITE, an answer in a reliable 183, and then repeat the answer in the next reliable 183. Thats because the answer has to be in the first reliable response sent back, which is the first 183. The SDP in the second 183 would be illegal, since it would be an offer, and those can't go in responses after the first SDP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Thu Mar 7 22:46:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12292 for ; Thu, 7 Mar 2002 22:46:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA17871 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 22:46:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16529; Thu, 7 Mar 2002 22:13:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16496 for ; Thu, 7 Mar 2002 22:13:16 -0500 (EST) Received: from mail03.netian.com (mail03.netian.com [203.231.231.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10250 for ; Thu, 7 Mar 2002 22:13:09 -0500 (EST) From: kimjuna@netian.com Received: by mail03.netian.com (5.1.048.1k) id 3C83E840000D6232 for sip@ietf.org; Fri, 8 Mar 2002 12:13:10 +0900 Message-ID: <3C83E84100002873@mail03.netian.com> Date: Fri, 8 Mar 2002 12:13:09 +0900 Subject: [SIP] maddr in Via and Request-URI meaning To: sip@ietf.org MIME-Version: 1.0 Importance: Normal Content-Type: text/plain; charset="EUC-KR" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA16497 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi all, "maddr" parameter is mentioned in some places of rfc2543bis-09 and related documents, but I cannot understand meaning of it and why, when it is used in Via header field. In section 18.1.1, "maddr" is used when the request is multicasted but "maddr" parameter in Request-URI is unclear in the meaning. Could you explain maddr parameter in simple way? Here is another wondering point in rfc2543bis-09. In section 18.1.1, it show following sentences. If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support UDP. It is anticipated that this behavior will be deprecated in a future revision of this specification. It seems to me these sentences say RFC 2543 compliant implementations do not support UDP, it is right? -- Junhwa Kim kimjuna@netian.com ________________________________________ 네띠앙 프리미엄 메일 오픈! (SMTP, 스팸메일 필터링 제공) http://www.netian.com/premium_mail/main.html _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 7 22:50:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12392 for ; Thu, 7 Mar 2002 22:50:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA18074 for sip-archive@odin.ietf.org; Thu, 7 Mar 2002 22:50:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16667; Thu, 7 Mar 2002 22:19:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16639 for ; Thu, 7 Mar 2002 22:19:24 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10398 for ; Thu, 7 Mar 2002 22:19:20 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g283JMh05911; Thu, 7 Mar 2002 21:19:22 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g283JMF06563; Thu, 7 Mar 2002 21:19:22 -0600 (CST) Received: from lmf.ericsson.se (rmt160208.am.ericsson.se [138.85.160.208]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA28106; Thu, 7 Mar 2002 21:19:20 -0600 (CST) Message-ID: <3C882E16.EC3DDD5F@lmf.ericsson.se> Date: Fri, 08 Mar 2002 05:20:54 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: Christer Holmberg , sip@ietf.org Subject: Re: [Sip] Question on manyfolks 05 References: <475FF955A05DD411980D00508B6D5FB00481E2D2@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A PRACK for a 1xx response that contained an answer can contain an offer (as stated in the draft), because the UAS will not generate an UPDATE until it receives the PRACK... therefore, in that situation, there is not a chance of having a glare condition... it is OK as it is specified. Gonzalo "Chen, Xin (Xin)" wrote: > > Hi Christer and Gonzalo, > > Thanks for your responses. > > I think the "MAY" in 100rel drafte is perfectly fine here. PRACK carries > offer can be very useful. Becuase for example, to sovle the 1 of N codecs > problem, I mean if the answer in 183 has multiple codecs for single media, > then the PRACK can be used to narrow them to one, and it is not likely > rejected by other peer. > > Even if it is rejected by 415, the UAC can learn the reason from 415 and try > again. > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 07 March 2002 8:03 > To: Gonzalo Camarillo > Cc: Chen, Xin (Xin); sip@ietf.org > Subject: Re: [Sip] Question on manyfolks 05 > > Hi, > > > >In section 11, > > > > > >None of the examples shows the PRACK/200 following the INVITE/183 as a > new > > >offer/answer exchange, but I think this is allowed, am I right? > > > > The PRACK can carry an anwer. About a PRACK carrying an offer, it should > > not be done, because you would not have a way of refusing the offer > > without refusing the PRACK itself. > > Chapter 5 in 100rel says: > > "If the UAC receives a reliable provisional response with an answer, it MAY > generate an > additional offer in the PRACK. If the UAS receives a PRACK with an > offer, it MUST place the answer in the 2xx to the PRACK." > > "MAY" does not mean the same as "SHOULD NOT". Do we need a change in the > text? > > However, IF the UAC receives a PRACK, with an offer it does NOT accept, what > about sending a 2xx response to the PRACK, and a 415 response to the INVITE? > Does it really matter if it refers to the session description in the INVITE, > or > in the PRACK, since the session setup has failed? > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 8 00:37:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14731 for ; Fri, 8 Mar 2002 00:37:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA22393 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 00:37:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20450; Thu, 7 Mar 2002 23:55:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20419 for ; Thu, 7 Mar 2002 23:55:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14059 for ; Thu, 7 Mar 2002 23:55:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g284u16Y029003; Thu, 7 Mar 2002 23:56:02 -0500 (EST) Message-ID: <3C884426.41CEB96E@dynamicsoft.com> Date: Thu, 07 Mar 2002 23:55:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Dean Willis , sip@ietf.org, "George Foti (LMC)" , "'Rohan Mahy'" Subject: Re: [Sip] Path header vs. pre-loaded route in Contact References: <15495.32703.821212.499226@lohi.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Dean Willis writes: > > > Then you aren't listening, because there have been ample reasons > given to > > use a home service proxy, and I will want such an extension in my > personal > > home phone so it's not just IMS. > > you send your invite to the proxy of your domain and that proxy can > forward the invite to your personal proxy that handles the speed dial or > whatever personal services you have. > > we can't have a function tht has nothing to do with registration and > that only is available if someone registers. the same solution must be > also available if someone doesn't want to register. > > finally, if you are going to push this through then please also edit the > bis so that it is not inconsistent with your path. I find nothing in the Path proposal inconsistent with bis. I also think I have fair shakes at claiming a pretty darn good sense of what is and is not consistent with bis. I will tell you what is NOT consistent. It is NOT consistent to use Record-Route in register, as has been pointed out by many. It is also NOT consistent to add ?Route header values to the Contact in the REGISTER to indicate an incoming path. The reason is, the biggest breakthrough we made in bis was to realize that the ultimate destination, and the hops for getting there, are really, really different things. All our attempts of glomming them together with the old routing stuff was ugly and error-prone. By putting the hops (conveyed in ?Route elements) back into the same header you use to convey the destination (Contact in the REGISTER), we are brought right back there once more. No way. For incoming calls, the best way, and most consistent way, for the registrar to learn about intermediate hops is a new header with semantics much like record-route, but scoped to a registration. I can also assure you there is nothing it can't do that appending a ?Route to the Contact can do. (I realize you did not propose this, so do not take it personally). Now, for outgoing requests. I sympathize with you, Juha, that the reasons for needing it in the IMS are not that compelling (avoiding the DB dip at the I-CSCF for mobile originated calls). However, I think it is well within the scope of bis to allow route discovery in any message that traverses some kind of path of proxies, so long as the scope is well defined. I had even thought about allowing Path (or something with a different name) in OPTIONS, to discover routes of even broader scope. Thus, I think it is perfectly within the bounds of SIP to discover an outbound path, scoped to a registration, through a register response. I agree its not terribly useful, but its not unreasonable, and definitely not counter to the very fabric of the sip architecture, as you have been claiming. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Fri Mar 8 04:03:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26336 for ; Fri, 8 Mar 2002 04:03:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13365 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 04:03:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11195; Fri, 8 Mar 2002 03:34:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11158 for ; Fri, 8 Mar 2002 03:34:06 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25645 for ; Fri, 8 Mar 2002 03:34:03 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g288Y3B00903; Fri, 8 Mar 2002 09:34:03 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g288Xvof014000; Fri, 8 Mar 2002 10:33:58 +0200 (EET) Message-ID: <3C8877BA.8453F45A@lmf.ericsson.se> Date: Fri, 08 Mar 2002 10:35:06 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Chen, Xin (Xin)" , sip@ietf.org Subject: Re: [Sip] Question on manyfolks 05 References: <475FF955A05DD411980D00508B6D5FB00481E2D2@en0033exch001u.uk.lucent.com> <3C882E16.EC3DDD5F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > A PRACK for a 1xx response that contained an answer can contain an offer > (as stated in the draft), because the UAS will not generate an UPDATE > until it receives the PRACK... therefore, in that situation, there is > not a chance of having a glare condition... it is OK as it is specified. I guess the issue is still what the UAS shall do if it doesn't accept the offer in the PRACK. Xin Chen's proposal was to send a 415 for the PRACK, and the UAC MAY then send a new PRACK. The problems with that proposal, as I see it, are the following: 1. This would be against the semantics of PRACK. 2. Since the UAS doesn't know if there will be a new PRACK or not, it doesn't know if it should "buffer" a possible 200 final response to be sent. I would also like to bring up a 200 rece condition scenario: If the UAS receives an offer in the PRACK, it must send the answer in the 200 to the PRACK. At the same time, however, it may send a 200 to the INVITE. And, the 200 for the INVITE MAY reach the UAC BEFORE the 200 for the PRACK. Now, that would mean that the UAC would have to "buffer" the 200 until it receives the the 200 for the PRACK, since it needs the answer which will be included in the 200 to the PRACK.... Regards, Christer Holmberg Ericsson Finland > > > Gonzalo > > "Chen, Xin (Xin)" wrote: > > > > Hi Christer and Gonzalo, > > > > Thanks for your responses. > > > > I think the "MAY" in 100rel drafte is perfectly fine here. PRACK carries > > offer can be very useful. Becuase for example, to sovle the 1 of N codecs > > problem, I mean if the answer in 183 has multiple codecs for single media, > > then the PRACK can be used to narrow them to one, and it is not likely > > rejected by other peer. > > > > Even if it is rejected by 415, the UAC can learn the reason from 415 and try > > again. > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: 07 March 2002 8:03 > > To: Gonzalo Camarillo > > Cc: Chen, Xin (Xin); sip@ietf.org > > Subject: Re: [Sip] Question on manyfolks 05 > > > > Hi, > > > > > >In section 11, > > > > > > > >None of the examples shows the PRACK/200 following the INVITE/183 as a > > new > > > >offer/answer exchange, but I think this is allowed, am I right? > > > > > > The PRACK can carry an anwer. About a PRACK carrying an offer, it should > > > not be done, because you would not have a way of refusing the offer > > > without refusing the PRACK itself. > > > > Chapter 5 in 100rel says: > > > > "If the UAC receives a reliable provisional response with an answer, it MAY > > generate an > > additional offer in the PRACK. If the UAS receives a PRACK with an > > offer, it MUST place the answer in the 2xx to the PRACK." > > > > "MAY" does not mean the same as "SHOULD NOT". Do we need a change in the > > text? > > > > However, IF the UAC receives a PRACK, with an offer it does NOT accept, what > > about sending a 2xx response to the PRACK, and a 415 response to the INVITE? > > Does it really matter if it refers to the session description in the INVITE, > > or > > in the PRACK, since the session setup has failed? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 8 04:18:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26668 for ; Fri, 8 Mar 2002 04:18:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14543 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 04:18:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10249; Fri, 8 Mar 2002 03:27:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10218 for ; Fri, 8 Mar 2002 03:27:50 -0500 (EST) Received: from hotmail.com (f4.law14.hotmail.com [64.4.21.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25548 for ; Fri, 8 Mar 2002 03:27:47 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 8 Mar 2002 00:27:18 -0800 Received: from 129.107.62.75 by lw14fd.law14.hotmail.msn.com with HTTP; Fri, 08 Mar 2002 08:27:18 GMT X-Originating-IP: [129.107.62.75] From: "SIP SIP" To: prsinha@unity.ncsu.edu Cc: sip@ietf.org Subject: Re: [Sip] Question Date: Fri, 08 Mar 2002 08:27:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Mar 2002 08:27:18.0927 (UTC) FILETIME=[0FABA9F0:01C1C67B] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org You should be able to distinguish between the two types of responses if u know what a protocol is in general ,I would like t say that this place it not for beginners. >From: "Prabhas Sinha" >To: >Subject: [Sip] Question >Date: Thu, 7 Mar 2002 10:10:15 -0500 > >Can someone please explain the differences between 100 & 183 informational >responses ? Why do we need these two ? > >Prabhas _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.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 daemon@optimus.ietf.org Fri Mar 8 04:33:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26993 for ; Fri, 8 Mar 2002 04:33:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA16177 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 04:33:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13536; Fri, 8 Mar 2002 04:06:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13510 for ; Fri, 8 Mar 2002 04:06:08 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26393 for ; Fri, 8 Mar 2002 04:05:50 -0500 (EST) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g288iOH22917; Fri, 8 Mar 2002 14:14:24 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B76.0030F56A ; Fri, 8 Mar 2002 14:24:45 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org cc: jdrosen@dynamicsoft.com, gonzalo.camarillo@lmf.ericsson.se Message-ID: <65256B76.0030F3C0.00@sampark.hss.hns.com> Date: Fri, 8 Mar 2002 14:24:40 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Clarification regarding the resolution for bug #113 (Overlapping transactions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi all, Need a clarification for the resolution that was done for the Bug #113 (Overlapping transaction model). The bugzilla closure entry for this bug reads: (http://www.sipwg.org/bugzilla/show_bug.cgi?id=113) However, a UA {\MAY} initiate a regular transaction while an {\INVITE} transaction is in progress. A UA {\MAY} also initiate an {\INVITE} transaction while a regular transaction is in progress. My query is: Can a UA initiate a regular transaction while another regular transaction is ongoing? As mentioned (on the same page), this is needed for multiple MESSAGEs by the UAC without waiting for a response for the previous messages. The new text that was added in Section 14.1 of bis-09 still seems to be unclear on this. Thanks for your time. Regards, Siddharth. -------------------- Siddharth Toshniwal @ Hughes Software Systems http://www.hssworld.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 daemon@optimus.ietf.org Fri Mar 8 08:05:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02738 for ; Fri, 8 Mar 2002 08:05:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00063 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 08:05:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26756; Fri, 8 Mar 2002 07:14:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26725 for ; Fri, 8 Mar 2002 07:14:30 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01146 for ; Fri, 8 Mar 2002 07:14:27 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 16jJGM-0008P6-00; Fri, 08 Mar 2002 14:14:18 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15496.43802.178377.559943@lohi.eng.song.fi> Date: Fri, 8 Mar 2002 14:14:18 +0200 To: Jonathan Rosenberg Cc: Dean Willis , sip@ietf.org, "George Foti (LMC)" , "'Rohan Mahy'" Subject: Re: [Sip] Path header vs. pre-loaded route in Contact In-Reply-To: <3C884426.41CEB96E@dynamicsoft.com> References: <15495.32703.821212.499226@lohi.eng.song.fi> <3C884426.41CEB96E@dynamicsoft.com> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > I find nothing in the Path proposal inconsistent with bis. I also think > I have fair shakes at claiming a pretty darn good sense of what is and > is not consistent with bis. i quess it depends on what someone means by inconsistency. for example, path changes the bis defined purpose of sending a register request and it changes the ua behavior when it sends a non-register requests. > I will tell you what is NOT consistent. It is NOT consistent to use > Record-Route in register, as has been pointed out by many. that is why i proposed that the header is called Record-Register-Route. i don't dispute the need for that for inbound requests. > Now, for outgoing requests. I sympathize with you, Juha, that the > reasons for needing it in the IMS are not that compelling (avoiding the > DB dip at the I-CSCF for mobile originated calls). However, I think it > is well within the scope of bis to allow route discovery in any message > that traverses some kind of path of proxies, so long as the scope is > well defined. I had even thought about allowing Path (or something with > a different name) in OPTIONS, to discover routes of even broader scope. > Thus, I think it is perfectly within the bounds of SIP to discover an > outbound path, scoped to a registration, through a register response. I > agree its not terribly useful, but its not unreasonable, and definitely > not counter to the very fabric of the sip architecture, as you have been > claiming. i could accept that if i could do the discovery without registering although as i have said and that you too admit, there is no real need for it in the 3gpp application and noone has not been describe any other application either where this the discovery would be needed for outbound calls. -- 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 daemon@optimus.ietf.org Fri Mar 8 08:11:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02945 for ; Fri, 8 Mar 2002 08:11:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00110 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 08:08:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25932; Fri, 8 Mar 2002 07:00:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25875 for ; Fri, 8 Mar 2002 07:00:43 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00232; Fri, 8 Mar 2002 07:00:41 -0500 (EST) Message-Id: <200203081200.HAA00232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Mar 2002 07:00:40 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-update-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP UPDATE Method Author(s) : J. Rosenberg Filename : draft-ietf-sip-update-01.txt Pages : 17 Date : 07-Mar-02 This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs), or provide SIP level information (such as credentials), but has no impact on the state of a dialog. This is very useful for updating information about a call before the call has been accepted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-update-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-update-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-update-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020307121033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307121033.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 daemon@optimus.ietf.org Fri Mar 8 08:14:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03084 for ; Fri, 8 Mar 2002 08:14:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00436 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 08:14:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25873; Fri, 8 Mar 2002 07:00:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25798 for ; Fri, 8 Mar 2002 07:00:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00217; Fri, 8 Mar 2002 07:00:34 -0500 (EST) Message-Id: <200203081200.HAA00217@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Mar 2002 07:00:34 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-manyfolks-resource-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Integration of Resource Management and SIP Author(s) : W. Marshall, G. Camarillo, J. Rosenberg Filename : draft-ietf-sip-manyfolks-resource-05.txt Pages : 28 Date : 07-Mar-02 This document defines a generic framework for preconditions which is extensible through IANA registration. This document also discusses how network quality of service can be made a precondition to establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-manyfolks-resource-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020307121020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-manyfolks-resource-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307121020.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 daemon@optimus.ietf.org Fri Mar 8 08:20:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03392 for ; Fri, 8 Mar 2002 08:20:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00688 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 08:20:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25864; Fri, 8 Mar 2002 07:00:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25793 for ; Fri, 8 Mar 2002 07:00:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00199; Fri, 8 Mar 2002 07:00:29 -0500 (EST) Message-Id: <200203081200.HAA00199@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Mar 2002 07:00:29 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-guidelines-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of SIP Extensions Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-04.txt Pages : 18 Date : 07-Mar-02 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-guidelines-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-guidelines-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020307121004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307121004.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 daemon@optimus.ietf.org Fri Mar 8 11:46:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15336 for ; Fri, 8 Mar 2002 11:46:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15339 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 11:46:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09632; Fri, 8 Mar 2002 10:31:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09587 for ; Fri, 8 Mar 2002 10:31:36 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10168 for ; Fri, 8 Mar 2002 10:31:34 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g28FVPh02813; Fri, 8 Mar 2002 09:31:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g28FVPP25521; Fri, 8 Mar 2002 09:31:25 -0600 (CST) Received: from lmf.ericsson.se (rmt160127.am.ericsson.se [138.85.160.127]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA01769; Fri, 8 Mar 2002 09:31:22 -0600 (CST) Message-ID: <3C88D9AE.48D08E9D@lmf.ericsson.se> Date: Fri, 08 Mar 2002 17:33:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: stoshniwal@hss.hns.com CC: sip@ietf.org, jdrosen@dynamicsoft.com References: <65256B76.0030F3C0.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Clarification regarding the resolution for bug #113 (Overlappingtransactions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Yes, you can overlap regular transactions. I believe this is not prohibited anywhere in the spec... if you have found some text prohibiting it, let us now and it will be removed. Regards, Gonzalo stoshniwal@hss.hns.com wrote: > > Hi all, > > Need a clarification for the resolution that was done > for the Bug #113 (Overlapping transaction model). > > The bugzilla closure entry for this bug reads: > (http://www.sipwg.org/bugzilla/show_bug.cgi?id=113) > > > However, a UA {\MAY} initiate a regular transaction while > an {\INVITE} transaction is in progress. A UA {\MAY} also > initiate an {\INVITE} transaction while a regular transaction > is in progress. > > > My query is: > > Can a UA initiate a regular transaction while another > regular transaction is ongoing? As mentioned (on the > same page), this is needed for multiple MESSAGEs by > the UAC without waiting for a response for the previous > messages. The new text that was added in Section 14.1 > of bis-09 still seems to be unclear on this. > > Thanks for your time. > > Regards, > Siddharth. > > -------------------- > Siddharth Toshniwal @ Hughes Software Systems > http://www.hssworld.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 8 13:37:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23268 for ; Fri, 8 Mar 2002 13:37:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23605 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 13:37:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20499; Fri, 8 Mar 2002 12:50:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20474 for ; Fri, 8 Mar 2002 12:50:56 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20361 for ; Fri, 8 Mar 2002 12:50:54 -0500 (EST) Message-ID: <20020308175055.88740.qmail@web11606.mail.yahoo.com> Received: from [131.107.3.75] by web11606.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 09:50:55 PST Date: Fri, 8 Mar 2002 09:50:55 -0800 (PST) From: Sean Olson Subject: Re: [Sip] URI and URL To: "Chen, Xin \(Xin\)" , sip@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB00481E574@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Every URL is a URI. See RFC2396, section 1.2: A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute (s) of that resource. Your SIP URL is also a SIP URI. For the purposes of SIP, the two terms are interchangeable. It is arguable whether the tel: URI is also a tel: URL depending on how you view telephone numbers. /sean --- "Chen, Xin (Xin)" wrote: > Hi, > > I have a very basic question, > > What is the difference between URI and URL? > > For example, if sip:xchen2@lucent.com is my SIP URI, > then what is my SIP > URL? > > In the SIPbis09, I see "SIP URI", "Request-URI" and > "Tel URL", can I say > "SIP URL", "Request-URL" and "Tel URI"? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 13:55:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24895 for ; Fri, 8 Mar 2002 13:55:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24998 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 13:55:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19968; Fri, 8 Mar 2002 12:40:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19939 for ; Fri, 8 Mar 2002 12:40:15 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19537 for ; Fri, 8 Mar 2002 12:40:11 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g28HdgK06958 for ; Fri, 8 Mar 2002 12:39:43 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Mar 2002 17:39:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00481E574@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: sip@ietf.org Date: Fri, 8 Mar 2002 17:39:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] URI and URL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a very basic question, What is the difference between URI and URL? For example, if sip:xchen2@lucent.com is my SIP URI, then what is my SIP URL? In the SIPbis09, I see "SIP URI", "Request-URI" and "Tel URL", can I say "SIP URL", "Request-URL" and "Tel URI"? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 13:59:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25181 for ; Fri, 8 Mar 2002 13:59:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25232 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 13:59:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22080; Fri, 8 Mar 2002 13:17:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22048 for ; Fri, 8 Mar 2002 13:17:01 -0500 (EST) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21832 for ; Fri, 8 Mar 2002 13:16:59 -0500 (EST) Message-ID: <20020308181700.62689.qmail@web11605.mail.yahoo.com> Received: from [131.107.3.86] by web11605.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 10:17:00 PST Date: Fri, 8 Mar 2002 10:17:00 -0800 (PST) From: Sean Olson Subject: RE: [Sip] URI and URL To: "Chen, Xin \(Xin\)" , sip@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB00481E581@en0033exch001u.uk.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- "Chen, Xin (Xin)" wrote: > Hi Sean, > > Thanks for your response. > > I still don't quite catch why they are > interchangeable for the purposes of > SIP since the text says the URL is the subset of > URI. According to the text, > I think the xchen2@lucent.com is like the URI and > SIP:xchen2@lucent.com or > mailto:xchen2@lucent.com is like the URL, beacuse > SIP:xchen2@lucent.com > futher narrows the resource by a protocol name. To be explicit, my SIP URL is "sip:sean.olson@isp.com". All URLs are also URIs (this is the part about URLs being a subset of the URI space). So, my SIP URI is "sip:sean.olson@isp.com" The scheme name ("sip:", "tel:", etc.) is an inherent part of the URI/URL/URN -- it cannot be removed without changing the semantics of the string. > > Also what do you mean by "It is arguable whether the > tel: URI is also a tel: > URL depending on how you view telephone numbers."? What I meant is that in some circumstances, a phone number refers to a literal device and in some circumstances a phone number refers to a service. (and there are other weird uses, but I will leave those for the PSTN experts). In the first case, you can think of it as a tel: URL (based on the definition of URL that I quoted). In the second case, you might prefer to call it a tel: URI (implying that the number might not convey a "primary access mechanism"). This is a finely split hair. The difference is largely academic as it all comes down to string processing in the end... /sean > Can you give two examples > one for Tel URL and one for Tel URI? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: 08 March 2002 17:51 > To: Chen, Xin (Xin); sip@ietf.org > Subject: Re: [Sip] URI and URL > > > Every URL is a URI. See RFC2396, section 1.2: > > A URI can be further classified as a locator, > a name, or both. The term "Uniform Resource > Locator" (URL) refers to the subset of URI > that identify resources via a representation of > their primary access mechanism (e.g., their > network "location"), rather than identifying > the resource by name or by some other attribute > (s) of that resource. > > Your SIP URL is also a SIP URI. For the purposes > of SIP, the two terms are interchangeable. It is > arguable whether the tel: URI is also a tel: URL > depending on how you view telephone numbers. > > /sean > > --- "Chen, Xin (Xin)" wrote: > > Hi, > > > > I have a very basic question, > > > > What is the difference between URI and URL? > > > > For example, if sip:xchen2@lucent.com is my SIP > URI, > > then what is my SIP > > URL? > > > > In the SIPbis09, I see "SIP URI", "Request-URI" > and > > "Tel URL", can I say > > "SIP URL", "Request-URL" and "Tel URI"? > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 14:14:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26736 for ; Fri, 8 Mar 2002 14:14:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26794 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 14:14:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21630; Fri, 8 Mar 2002 13:06:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21598 for ; Fri, 8 Mar 2002 13:06:45 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21094 for ; Fri, 8 Mar 2002 13:06:43 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g28I6DT16333 for ; Fri, 8 Mar 2002 13:06:13 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Mar 2002 18:06:12 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00481E581@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Sean Olson , "Chen, Xin (Xin)" , sip@ietf.org Subject: RE: [Sip] URI and URL Date: Fri, 8 Mar 2002 18:06:11 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Sean, Thanks for your response. I still don't quite catch why they are interchangeable for the purposes of SIP since the text says the URL is the subset of URI. According to the text, I think the xchen2@lucent.com is like the URI and SIP:xchen2@lucent.com or mailto:xchen2@lucent.com is like the URL, beacuse SIP:xchen2@lucent.com futher narrows the resource by a protocol name. Also what do you mean by "It is arguable whether the tel: URI is also a tel: URL depending on how you view telephone numbers."? Can you give two examples one for Tel URL and one for Tel URI? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Sean Olson [mailto:seancolson@yahoo.com] Sent: 08 March 2002 17:51 To: Chen, Xin (Xin); sip@ietf.org Subject: Re: [Sip] URI and URL Every URL is a URI. See RFC2396, section 1.2: A URI can be further classified as a locator, a name, or both. The term "Uniform Resource Locator" (URL) refers to the subset of URI that identify resources via a representation of their primary access mechanism (e.g., their network "location"), rather than identifying the resource by name or by some other attribute (s) of that resource. Your SIP URL is also a SIP URI. For the purposes of SIP, the two terms are interchangeable. It is arguable whether the tel: URI is also a tel: URL depending on how you view telephone numbers. /sean --- "Chen, Xin (Xin)" wrote: > Hi, > > I have a very basic question, > > What is the difference between URI and URL? > > For example, if sip:xchen2@lucent.com is my SIP URI, > then what is my SIP > URL? > > In the SIPbis09, I see "SIP URI", "Request-URI" and > "Tel URL", can I say > "SIP URL", "Request-URL" and "Tel URI"? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 14:24:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27534 for ; Fri, 8 Mar 2002 14:24:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27973 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 14:24:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24506; Fri, 8 Mar 2002 13:51:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24462 for ; Fri, 8 Mar 2002 13:51:10 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24555 for ; Fri, 8 Mar 2002 13:51:07 -0500 (EST) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000063652; Fri, 08 Mar 2002 18:51:07 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <475FF955A05DD411980D00508B6D5FB00481E581@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00481E581@en0033exch001u.uk.lucent.com> Date: Fri, 8 Mar 2002 18:51:06 +0000 To: "Chen, Xin (Xin)" , Sean Olson , sip@ietf.org From: Lawrence Conroy Subject: RE: [Sip] URI and URL Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 6:06 pm +0000 8/3/02, Chen, Xin (Xin) wrote: >Hi Sean, >Also what do you mean by "It is arguable whether the tel: URI is also a tel: >URL depending on how you view telephone numbers."? Can you give two examples >one for Tel URL and one for Tel URI? To which I reply, Hi Sean, Xin, Folks, This one has been puzzling me for a long while (since before Antti codified the "URL" in 2806). Here's my attempt:: You could argue that (with the onset of ENUM) a tel: URL doesn't make sense. You don't necessarily have any idea from this what resource is actually implied or available, so you could argue that it's a tel: URI. If you wanted to make a rule on this, perhaps a tel: URI would be the value that you apply to an ENUM lookup, whilst a tel: URL might be the result of an ENUM lookup that indicates that your client has to dial this (via SIP, or even via some smart dialer software plugged into your PSTN phone). They look exactly the same but from context you differentiate. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 14:31:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28120 for ; Fri, 8 Mar 2002 14:31:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29013 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 14:31:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24940; Fri, 8 Mar 2002 13:55:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24906 for ; Fri, 8 Mar 2002 13:55:42 -0500 (EST) Received: from www.guate.net (IDENT:root@www.guate.net [200.12.63.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24874 for ; Fri, 8 Mar 2002 13:55:33 -0500 (EST) Received: from smtp0412.mail.yahoo.com (aworklan021126.netvigator.com [203.198.127.126]) by www.guate.net (8.9.3/8.9.3) with SMTP id MAA02978; Fri, 8 Mar 2002 12:54:04 -0600 Message-Id: <200203081854.MAA02978@www.guate.net> Reply-To: libertyHGH@btamail.net.cn From: libertyHGH331611@btamail.net.cn To: sip@doctor.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Mar 2002 10:57:58 -0800 Subject: [Sip] == Feel & Look 10 Years Younger in 10 Weeks With HGH == 33161186544333222221111 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One more bulk email --- aren't you the least bit curious to find out what it's about? Well, call us Toll Free at 1-888-248-4571. OR, read on ............................................... HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? (This product works best for people over 35) Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us anytime (24hrs) TOLL FREE 1-888-248-4571 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-248-4571. If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Call us now 1-888-248-4571 Offer expires March 30, 2002 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and enter remove in the email subject line then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** -------------------------------------------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 14:35:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28465 for ; Fri, 8 Mar 2002 14:35:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29836 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 14:35:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23821; Fri, 8 Mar 2002 13:43:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23792 for ; Fri, 8 Mar 2002 13:42:59 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23781 for ; Fri, 8 Mar 2002 13:42:57 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g28IgSl28910 for ; Fri, 8 Mar 2002 12:42:28 -0600 Message-ID: <009d01c1c6d0$d7a5f780$bb036e3f@TXDWILLIS2> From: "Dean Willis" To: Date: Fri, 8 Mar 2002 12:41:21 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01C1C69E.8CC0C2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] SIP MIB Work Plan Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_009A_01C1C69E.8CC0C2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, the SIP MIB document has been floating around for a while, and we've = done a light WGLC on it. However, this doc reflects RFC 2543, not bis. We have two choices: 1) Work to issue a MIB for 2543, then do a revised one for the new bis = RFC 2) Move straight to BIS. I don't believe I've seen a huge demand for a MIB RFC for 2543, but not = everybody talks to me about this . . . So what do you people think? -- Dean ------=_NextPart_000_009A_01C1C69E.8CC0C2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ok, the SIP MIB document has been = floating around=20 for a while, and we've done a light WGLC on it.
 
However, this doc reflects RFC 2543, = not=20 bis.
 
We have two choices:
 
1) Work to issue a MIB for 2543, then = do a revised=20 one for the new bis RFC
 
2) Move straight to BIS.
 
I don't believe I've seen a huge demand = for a MIB=20 RFC for 2543, but not everybody talks to me about this . . = .
 
So what do you people = think?
 
--
Dean
------=_NextPart_000_009A_01C1C69E.8CC0C2E0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 15:13:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01011 for ; Fri, 8 Mar 2002 15:13:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03097 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 15:13:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26472; Fri, 8 Mar 2002 14:11:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26431 for ; Fri, 8 Mar 2002 14:11:13 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26231 for ; Fri, 8 Mar 2002 14:11:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.162]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g28JBU6Y029573; Fri, 8 Mar 2002 14:11:30 -0500 (EST) Message-ID: <3C890CA7.5D57908C@dynamicsoft.com> Date: Fri, 08 Mar 2002 14:10:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "Chen, Xin (Xin)" , sip@ietf.org Subject: Re: [Sip] URI and URL References: <20020308181700.62689.qmail@web11605.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > > --- "Chen, Xin (Xin)" wrote: > > Hi Sean, > > > > Thanks for your response. > > > > I still don't quite catch why they are > > interchangeable for the purposes of > > SIP since the text says the URL is the subset of > > URI. According to the text, > > I think the xchen2@lucent.com is like the URI and > > SIP:xchen2@lucent.com or > > mailto:xchen2@lucent.com is like the URL, beacuse > > SIP:xchen2@lucent.com > > futher narrows the resource by a protocol name. > > To be explicit, my SIP URL is > "sip:sean.olson@isp.com". All URLs are also URIs > (this is the part about URLs being a subset of the > URI space). So, my SIP URI is "sip:sean.olson@isp.com" One of the (minor) changes in bis was to consistently call it a SIP URI, not a SIP URL. This is based on current thinking in the URN/URI/URL community. Please see: http://search.ietf.org/internet-drafts/draft-mealling-uri-ig-02.txt for a discussion of the differences, or lack thereof. For the most of the rest of us, the terms URI and URL are interchangeable, and refer to the same thing - sip:user@domain, for example. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Fri Mar 8 17:09:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06940 for ; Fri, 8 Mar 2002 17:09:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09715 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 17:09:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01155; Fri, 8 Mar 2002 14:51:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01089 for ; Fri, 8 Mar 2002 14:51:47 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29609; Fri, 8 Mar 2002 14:51:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06511; Fri, 8 Mar 2002 14:51:14 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA06673; Fri, 8 Mar 2002 14:51:16 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Mar 2002 14:51:15 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CC36@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Fri, 8 Mar 2002 14:51:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Change in List Policy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We have received permission to change the policy of sip and sipping to membership post allowed, others require moderator (that's me) approval. This should substantially reduce the spam we have been experiencing, and I get more work to do -- oh joy. I endeavor to approve legit postings held for moderator approval within minutes to hours, but it could take somewhat longer in extenuating circumstances. There have been a LOT of stupid things happening lately. I forcibly unsubscribe about 2 people A DAY. 1. Companies are turning on spam filters more aggressive than MailMan's causing me to get mail. I hope this change will eliminate most of those. If your system does this a lot, I delete you. 2. People are turning out-of-the-office replies on without setting their subscription to no-mail. 3. We have gotten several cases of a subscriber coming in from some free email service like yahoo with forwarding to some other account. The forwarded account gets some problem and sends me email, but I don't have a subscriber by that name. I'm stuck getting email on every sip message until it gets rectified, or I use a utility that probes every email address looking for the offender. I DON'T APPRECIATE THIS ONE, so if you forward DON'T GO OVERQUOTA. 4. For whatever reason, the number of SMTP routing errors is on the increase. Before you say it won't happen to you, let me tell you that it has happened to plenty of places who know more about SMPT than you and I put together. There is not much you can do about this. Your list administrator Brian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 8 18:56:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12124 for ; Fri, 8 Mar 2002 18:56:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14369 for sip-archive@odin.ietf.org; Fri, 8 Mar 2002 18:56:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12335; Fri, 8 Mar 2002 18:06:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12303 for ; Fri, 8 Mar 2002 18:06:13 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09998 for ; Fri, 8 Mar 2002 18:06:10 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g28N6Dh28957; Fri, 8 Mar 2002 17:06:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g28N6Ck29795; Fri, 8 Mar 2002 17:06:12 -0600 (CST) Received: from lmf.ericsson.se (rmt160127.am.ericsson.se [138.85.160.127]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA15106; Fri, 8 Mar 2002 17:06:09 -0600 (CST) Message-ID: <3C89443D.600D6FE@lmf.ericsson.se> Date: Sat, 09 Mar 2002 01:07:41 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip CC: Henning Schulzrinne , oran@cisco.com, Dean Willis , "Brian Rosenberg (EUS)" , Joerg Ott , Allison Mankin , Jonathan Rosemberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Reason draft WG item? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, when working on different SIP WG items, we have identified a common piece of functionality that is needed in several scenarios. It makes no sense to define the same funcionality several times, so we have defined it in a separate stand-alone document: http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt This functionality has been found useful in the following WG items: o ISUP/SIP mapping o 155 responses to UPDATE, which are useful to solve the "heterogeneous error response forking problem", which includes the migration from SDP to SDPng (documented in an MMUSIC WG item: draft-ietf-mmusic-sdpng-trans-00.txt) o 3pcc o manyfolks Therefore, we would like ask the chairs and the WG to consider the Reason phrase draft as a WG item. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Sat Mar 9 04:26:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07262 for ; Sat, 9 Mar 2002 04:26:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17036 for sip-archive@odin.ietf.org; Sat, 9 Mar 2002 04:26:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16192; Sat, 9 Mar 2002 03:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16166 for ; Sat, 9 Mar 2002 03:53:27 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07034 for ; Sat, 9 Mar 2002 03:50:51 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g298orZc022211 for ; Sat, 9 Mar 2002 09:50:54 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g298orof022589 for ; Sat, 9 Mar 2002 10:50:53 +0200 (EET) Message-ID: <3C89CD3F.4D1EA6DA@lmf.ericsson.se> Date: Sat, 09 Mar 2002 10:52:15 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 200 UPDATE race condition Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Another race condition... Assume UA_B sends a 200 to an INVITE, without SDP (it has been sent earlier in a reliable 18x). Then it receives an UPDATE, with a new offer. Now, there are two possible scenarios: 1. UA_A (the caller) receives the 200 for the INVITE, sends ACK, and then sends UPDATE, but for whatever reason the UPDATE reaches UA_B before the ACK. 2. UA_A sends the UPDATE at the same time as UA_B sends the 200 for the INVITE, ie we have a race condition. Now, UA_B doesn't know which case is true. Now, one could argue that UA_B doesn't have to care. It receives an UPDATE, accepts it, and that's it. Also, UA_B will receive the 200 for the INVITE first, but it will wait for the UPDATE response. So, IF both UA_A and UA_B handle the situation this way I guess things could work. However, UA_B may want to send 491 for the UPDATE, since it hasn't received ACK for the INVITE. Is it allowed to do so - EVEN if there is no answer/offer conflict in this case (since the 200 didn't contain SDP)? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 10 13:50:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12359 for ; Sun, 10 Mar 2002 13:50:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05453 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 13:50:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04741; Sun, 10 Mar 2002 13:28:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04709 for ; Sun, 10 Mar 2002 13:28:40 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12107 for ; Sun, 10 Mar 2002 13:28:37 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2AIS4l18056; Sun, 10 Mar 2002 12:28:04 -0600 Message-ID: <015d01c1c861$5142f4d0$55fa403f@C1893415A> From: "Dean Willis" To: "Gonzalo Camarillo" , "sip" Cc: "Henning Schulzrinne" , , "Brian Rosenberg \(EUS\)" , "Joerg Ott" , "Allison Mankin" , "Jonathan Rosemberg" References: <3C89443D.600D6FE@lmf.ericsson.se> Date: Sun, 10 Mar 2002 12:28:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Reason draft WG item? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The usual drill . . .active discussion of the draft on the list, consensus to adopt, approval by the AD, setting a milestone, then we have a WG task. It take it you'll want to have some discussion of this on the agenda at IETF 53. -- Dean ----- Original Message ----- From: "Gonzalo Camarillo" To: "sip" Cc: "Henning Schulzrinne" ; ; "Dean Willis" ; "Brian Rosenberg (EUS)" ; "Joerg Ott" ; "Allison Mankin" ; "Jonathan Rosemberg" Sent: Friday, March 08, 2002 5:07 PM Subject: Reason draft WG item? > Hello, > > when working on different SIP WG items, we have identified a common > piece of functionality that is needed in several scenarios. It makes no > sense to define the same funcionality several times, so we have defined > it in a separate stand-alone document: > > http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt > > This functionality has been found useful in the following WG items: > > o ISUP/SIP mapping > > o 155 responses to UPDATE, which are useful to solve the "heterogeneous > error response forking problem", which includes the migration from SDP > to SDPng (documented in an MMUSIC WG item: > draft-ietf-mmusic-sdpng-trans-00.txt) > > o 3pcc > > o manyfolks > > Therefore, we would like ask the chairs and the WG to consider the > Reason phrase draft as a WG item. > > Thanks, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Sun Mar 10 14:17:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12741 for ; Sun, 10 Mar 2002 14:17:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06728 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 14:17:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05628; Sun, 10 Mar 2002 13:56:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05598 for ; Sun, 10 Mar 2002 13:56:17 -0500 (EST) Received: from kenny.siteprotect.com (kenny.siteprotect.com [64.26.0.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12460 for ; Sun, 10 Mar 2002 13:56:14 -0500 (EST) Received: from joshua (host217-39-58-230.in-addr.btopenworld.com [217.39.58.230]) by kenny.siteprotect.com (8.9.3/8.9.3) with ESMTP id MAA00372 for ; Sun, 10 Mar 2002 12:55:45 -0600 From: "Ofir Arkin" To: Date: Sun, 10 Mar 2002 18:55:31 -0000 Message-ID: <001101c1c865$2c213370$0a01a8c0@joshua> 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.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] To tag with 16.6 Request Forwarding Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 16.6 point 8 "Add a Via header field value": It is suggested that a cryptographic hash will be used for the value in the branch parameter used for loop detection. The text suggests that computing a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI and the CSeq header field will be done. My question is the following: When the proxy receives a request, an INVITE, the to field does not have a tag yet...? Or am I am getting this wrong? Ofir Arkin _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 10 17:46:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15283 for ; Sun, 10 Mar 2002 17:46:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14565 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 17:46:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13250; Sun, 10 Mar 2002 17:12:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13185 for ; Sun, 10 Mar 2002 17:12:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14790 for ; Sun, 10 Mar 2002 17:12:01 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2AMBYl19137; Sun, 10 Mar 2002 16:11:34 -0600 Message-ID: <00c501c1c880$8a3b3670$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "Flemming Andreasen" , , , , "Rohan Mahy" Date: Sun, 10 Mar 2002 16:11:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Privacy Draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We'd like to open discussion for working group last call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-04.txt This is part of the "Bundle 2" group needed by 3GPP. The working group last call discussion period will close immediately after IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as possible thereafter. Please note that this is NOT considered a final solution to our chartered "privacy" goal. It is however an interim step believed suitable for a subset of networks sufficient to justify an applicability-scoped extension. -- Dean Willis SIP WG Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 10 17:47:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15313 for ; Sun, 10 Mar 2002 17:47:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14619 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 17:48:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13290; Sun, 10 Mar 2002 17:12:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13187 for ; Sun, 10 Mar 2002 17:12:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14793 for ; Sun, 10 Mar 2002 17:12:02 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2AMBZl19140; Sun, 10 Mar 2002 16:11:35 -0600 Message-ID: <00c601c1c880$8aa4a6a0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: , , , "Rohan Mahy" Date: Sun, 10 Mar 2002 16:11:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Update draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We'd like to open discussion for working group last call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-update-01.txt This is part of the "Bundle 2" group needed by 3GPP. The working group last call discussion period will close immediately after IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as possible therafter. -- Dean Willis SIP WG Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 10 17:48:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15331 for ; Sun, 10 Mar 2002 17:48:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14633 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 17:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13222; Sun, 10 Mar 2002 17:12:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13183 for ; Sun, 10 Mar 2002 17:12:06 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14789 for ; Sun, 10 Mar 2002 17:12:01 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2AMBVl19134; Sun, 10 Mar 2002 16:11:31 -0600 Message-ID: <00c401c1c880$89c717e0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "Rohan Mahy" , , , , "Flemming Andreasen" Date: Sun, 10 Mar 2002 16:09:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Informational Draft on Media Authorization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We'd like to open discussion for a working group lst call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-call-auth-04.txt Please note that this is not a standards-track draft. It defines a p-class header used for interworking with a restricted set of QoS policy managers potentially used in some cable and wirless networks, It is also part of the "Bundle 2" set deemed critical by 3GPP. We plan to conclude WGLC on or about 25 March 2002 and advance to IETF last call as soon as possible thereafter. -- Dean Willis SIP WG co-chair. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 10 22:57:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20060 for ; Sun, 10 Mar 2002 22:57:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA28063 for sip-archive@odin.ietf.org; Sun, 10 Mar 2002 22:57:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27157; Sun, 10 Mar 2002 22:32:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA27126 for ; Sun, 10 Mar 2002 22:32:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19856 for ; Sun, 10 Mar 2002 22:32:51 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2B3WIS26517; Sun, 10 Mar 2002 21:32:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2B3WIp26844; Sun, 10 Mar 2002 21:32:18 -0600 (CST) Received: from lmf.ericsson.se (rmt160238.am.ericsson.se [138.85.160.238]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA23258; Sun, 10 Mar 2002 21:32:14 -0600 (CST) Message-ID: <3C8C25B1.B704B2BB@lmf.ericsson.se> Date: Mon, 11 Mar 2002 05:34:09 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip , Henning Schulzrinne , oran@cisco.com, "Brian Rosenberg (EUS)" , Joerg Ott , Allison Mankin , Jonathan Rosemberg References: <3C89443D.600D6FE@lmf.ericsson.se> <015d01c1c861$5142f4d0$55fa403f@C1893415A> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Reason draft WG item? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Dean Willis wrote: > > The usual drill . . .active discussion of the draft on the list, consensus > to adopt, approval by the AD, setting a milestone, then we have a WG task. > It take it you'll want to have some discussion of this on the agenda at IETF > 53. Sure, you can add this item to the agenda. Thanks, Gonzalo > -- > Dean > > ----- Original Message ----- > From: "Gonzalo Camarillo" > To: "sip" > Cc: "Henning Schulzrinne" ; ; "Dean > Willis" ; "Brian Rosenberg (EUS)" > ; "Joerg Ott" ; > "Allison Mankin" ; "Jonathan Rosemberg" > > Sent: Friday, March 08, 2002 5:07 PM > Subject: Reason draft WG item? > > > Hello, > > > > when working on different SIP WG items, we have identified a common > > piece of functionality that is needed in several scenarios. It makes no > > sense to define the same funcionality several times, so we have defined > > it in a separate stand-alone document: > > > > http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt > > > > This functionality has been found useful in the following WG items: > > > > o ISUP/SIP mapping > > > > o 155 responses to UPDATE, which are useful to solve the "heterogeneous > > error response forking problem", which includes the migration from SDP > > to SDPng (documented in an MMUSIC WG item: > > draft-ietf-mmusic-sdpng-trans-00.txt) > > > > o 3pcc > > > > o manyfolks > > > > Therefore, we would like ask the chairs and the WG to consider the > > Reason phrase draft as a WG item. > > > > Thanks, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Mon Mar 11 04:21:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02275 for ; Mon, 11 Mar 2002 04:21:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26016 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 04:21:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24336; Mon, 11 Mar 2002 03:57:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24308 for ; Mon, 11 Mar 2002 03:57:36 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01900 for ; Mon, 11 Mar 2002 03:57:29 -0500 (EST) From: mgovind@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g2B8ZvH02278; Mon, 11 Mar 2002 14:05:58 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B79.0030393F ; Mon, 11 Mar 2002 14:16:43 +0530 X-Lotus-FromDomain: HSSBLR To: sip@ietf.org, sip-implementors@cs.columbia.edu Message-ID: <65256B79.0030380E.00@sampark.hss.hns.com> Date: Mon, 11 Mar 2002 14:16:39 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Line folding of Sip Headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I will be thankful if you can clarify my doubt regarding allowing line folding in SipHeaders. In real world senarios ,whether any body is sending a linefolded Sip message , because most part of a sip message will be generated not by hand . If our policy is to to keep it simple .... , why are we allowing line folding and making implementations more complex.Why cant we have a complete signaling without line folding. If I am wrong please correct me. regards mahesh@Hughes Software systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 08:59:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08184 for ; Mon, 11 Mar 2002 08:59:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA17550 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 08:59:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14947; Mon, 11 Mar 2002 08:24:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14915 for ; Mon, 11 Mar 2002 08:24:45 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07160 for ; Mon, 11 Mar 2002 08:24:40 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id IAA25943; Mon, 11 Mar 2002 08:23:36 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B79.00498EA8 ; Mon, 11 Mar 2002 08:23:26 -0500 X-Lotus-FromDomain: MITEL To: mgovind@hss.hns.com, Tom_Gray@Mitel.COM cc: sip@ietf.org, sip-implementors@cs.columbia.edu Message-ID: <85256B79.00498C5D.00@kanmta01.software.mitel.com> Date: Mon, 11 Mar 2002 08:23:22 -0500 Subject: Re: [Sip] Line folding of Sip Headers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 03/11/2002 08:23 AM It has always been my impression that human readability is seen as a major advantage of text-based messaging. ASN.1 is criticised since it requires special analysers to interpret messages and that this both adds expense and delays development. mgovind@hss.hns.com on 03/11/2002 03:46:39 AM To: sip@ietf.org, sip-implementors@cs.columbia.edu cc: (bcc: Tom Gray/Kan/Mitel) Subject: [Sip] Line folding of Sip Headers Hi, I will be thankful if you can clarify my doubt regarding allowing line folding in SipHeaders. In real world senarios ,whether any body is sending a linefolded Sip message , because most part of a sip message will be generated not by hand . If our policy is to to keep it simple .... , why are we allowing line folding and making implementations more complex.Why cant we have a complete signaling without line folding. If I am wrong please correct me. regards mahesh@Hughes Software systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 09:05:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08483 for ; Mon, 11 Mar 2002 09:05:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18291 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 09:05:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16555; Mon, 11 Mar 2002 08:39:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16519 for ; Mon, 11 Mar 2002 08:38:56 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07627 for ; Mon, 11 Mar 2002 08:38:47 -0500 (EST) From: mgovind@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g2BDCCH03262; Mon, 11 Mar 2002 18:42:12 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B79.00498416 ; Mon, 11 Mar 2002 18:52:59 +0530 X-Lotus-FromDomain: HSSBLR To: Tom_Gray@Mitel.COM cc: Tom_Gray@Mitel.COM, sip@ietf.org, sip-implementors@cs.columbia.edu Message-ID: <65256B79.004982E9.00@sampark.hss.hns.com> Date: Mon, 11 Mar 2002 18:52:55 +0530 Subject: Re: [Sip] Line folding of Sip Headers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org HI, But how will line folding help for much readability.I think ASN is a different case. In the case of text based messages ,the cost of implementing a parser which can handle line folding is obviously very high compared to is usefulness.Also if somebody wants to open a message a using a text editor, most text editors today will fold it and show it. regards mahesh Tom_Gray@Mitel.COM on 03/11/2002 06:53:22 PM To: Mahesh Govind/HSSBLR, Tom_Gray@Mitel.COM cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] Line folding of Sip Headers From: Tom Gray@MITEL on 03/11/2002 08:23 AM It has always been my impression that human readability is seen as a major advantage of text-based messaging. ASN.1 is criticised since it requires special analysers to interpret messages and that this both adds expense and delays development. mgovind@hss.hns.com on 03/11/2002 03:46:39 AM To: sip@ietf.org, sip-implementors@cs.columbia.edu cc: (bcc: Tom Gray/Kan/Mitel) Subject: [Sip] Line folding of Sip Headers Hi, I will be thankful if you can clarify my doubt regarding allowing line folding in SipHeaders. In real world senarios ,whether any body is sending a linefolded Sip message , because most part of a sip message will be generated not by hand . If our policy is to to keep it simple .... , why are we allowing line folding and making implementations more complex.Why cant we have a complete signaling without line folding. If I am wrong please correct me. regards mahesh@Hughes Software systems This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 10:31:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11613 for ; Mon, 11 Mar 2002 10:31:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24242 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 10:31:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21932; Mon, 11 Mar 2002 10:00:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13253 for ; Sun, 10 Mar 2002 17:12:16 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14795 for ; Sun, 10 Mar 2002 17:12:05 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2AMBcl19154; Sun, 10 Mar 2002 16:11:38 -0600 Message-ID: <00ca01c1c880$8c8d8ae0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: , "Gonzalo Camarillo" , , "Rohan Mahy" , Date: Sun, 10 Mar 2002 16:11:04 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] WGLC for Manyfolks draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We'd like to open discussion for working group last call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks-resource-05.t xt This is part of the "Bundle 2" group needed by 3GPP. The working group last call discussion period will close immediately after IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as possible thereafter. -- Dean Willis SIP WG Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 10:32:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11656 for ; Mon, 11 Mar 2002 10:32:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24440 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 10:32:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22381; Mon, 11 Mar 2002 10:04:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22350 for ; Mon, 11 Mar 2002 10:04:06 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10809 for ; Mon, 11 Mar 2002 10:04:02 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BF3Yd16067; Mon, 11 Mar 2002 07:03:35 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA01795; Mon, 11 Mar 2002 07:03:33 -0800 (PST) Message-ID: <3C8CC744.FDEF8CF0@cisco.com> Date: Mon, 11 Mar 2002 10:03:33 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Questions/Comments on privacy-04 draft References: <32CD630F6CBED411AE180008C7894CBC0C0374BB@lmc37.lmc.ericsson.se> <3C84ED04.2940DD69@cisco.com> <15493.29699.88648.465434@thomasm-u1.cisco.com> <001701c1c4ba$2b6d5070$133fed0c@C1893415A> <15494.9111.53500.76084@thomasm-u1.cisco.com> <3C862765.2B40FB23@cisco.com> <15494.12980.946950.813481@thomasm-u1.cisco.com> <3C863881.BD5A8C2A@cisco.com> <15494.16009.712770.624526@thomasm-u1.cisco.com> <3C8645F6.7E849A1A@cisco.com> <15494.19272.739953.153785@thomasm-u1.cisco.com> <3C867179.B9A78671@cisco.com> <15495.39946.633344.638185@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Flemming Andreasen writes: > > Michael Thomas wrote: > > > I think you're misunderstanding me. This section implies > > > that a UA should prefer a screen=no RPID over a > > > screen=yes RPID. That seems reversed to me. > > > > Not within a single Remote-Party-Id - if it both indicates that it is trustworthy ("yes") and non > > trustworthy ("no"), then I would say it's not trustworthy. If on the other hand there is one > > Remote-Party-Id that was screened ("yes") and one there was not ("no"), then I agree you'd be > > better off using the screened one, but that is not what the precedence is talking about. > > OK, I'm now even more confused. It says that there > aren't supposed to be multiple screen= tags though. As in, a > compliant proxy shouldn't do that. If what you're > saying is that if a UA receives a RPID with multiple > screen= tags it should consider it untrusted, I agree > but the text is not very clear here: Hmm, it says "Multiple rpi-screen parameters MAY be present in a Remote-Party-ID - if both "yes" and "no" are present, "no" will take precedence." Notice that it says "*a* Remote-Party-ID", not multiple. > it seems to > saying that if you get multiple *RPID's* you > should prefer screen=no, which I think we agree > is not how it should be interpreted. Right. -- Flemming > > > Mike -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 11:42:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14118 for ; Mon, 11 Mar 2002 11:42:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28804 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 11:42:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26224; Mon, 11 Mar 2002 11:03:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26198 for ; Mon, 11 Mar 2002 11:03:36 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12749 for ; Mon, 11 Mar 2002 11:03:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GST00K01GKKTR@firewall.wcom.com> for sip@ietf.org; Mon, 11 Mar 2002 16:02:44 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GST00JICGKJSH@firewall.wcom.com> for sip@ietf.org; Mon, 11 Mar 2002 16:02:43 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GST00301GK2BU@pmismtp03.wcomnet.com> for sip@ietf.org; Mon, 11 Mar 2002 16:02:43 +0000 (GMT) Received: from ajohnston ([166.38.62.100]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GST002CWGJT37@pmismtp03.wcomnet.com> for sip@ietf.org; Mon, 11 Mar 2002 16:02:18 +0000 (GMT) Date: Mon, 11 Mar 2002 10:02:15 -0600 From: Alan Johnston To: "'SIP'" Message-id: <002201c1c916$1dda6500$0c392ca6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Replaces and 481 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit All, I'd like to discuss an open issue in the current Replaces draft (http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-00.txt) in Section 5.1: " If no match is found, the UAS MUST ignore the header and process the INVITE normally. OPEN ISSUE: If no match is found, should the UAS ignore the header and process normally, or return a 481?" The current use of Replaces in the Transfer and Service Examples draft uses the current behavior that the header is ignored if no dialog matches. Also, since no Require: replaces header is present in the current call flows, a UA that does not understand Replaces also just ignores the header. This becomes an issue in attended transfer in the presence of forking or misrouting, in which the triggered INVITE with the Replaces header may reach the wrong endpoint. The current solution to this is to use the Accept-Contact only=true header so that the wrong endpoint will reject the INVITE rather than accepting it. However, the requirement on a UAS to reject a request in which the Accept-Contact only=true header is present is only a SHOULD. Also, a Require: prefs would be needed in the triggered INVITE to make certain that the UAS understands the Accept-Contact header. This could cause an attended transfer to fail with a 420 response because the UAS does not support Caller Prefs when in fact it may support Replaces and the transfer should succeed. An alternative is to change the Replaces behavior to say that a matching failure generates a 481 response. If the triggered INVITE with the Replaces contained a Require: replaces header, then one of three things will happen when a UAS receives it: 1. The UA does not understand Replaces and will return a 420. This means that an attended transfer will fail, and the transferor should fall back to the unattended transfer which does not use the Replaces header. 2. The UA does understand Replaces but the dialog does not generate a match and a 481 is returned. If this is caused by misrouting, it is an error condition. The transferor could try sending the REFER to the other party (see if the transfer works in the other direction). With forking, the incorrect endpoints should all return a 481 while the correct endpoint will return a 200 resulting in a successful transfer. 3. The UA does understand Replaces matches and the dialog matches and a 200 OK is sent. The attended transfer succeeds. This way, the transferor knows the outcome of the transfer and each failure suggests a fallback or course of action to resolve the problem. Although I am not in favor of most uses of the Require header, I like this approach. Note that the Require: replaces would be in the triggered INVITE only, and not in initial INVITEs. The normal option discovery mechanisms (Allow: REFER and Supported: replaces) would be used most of the time. Comments? Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.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 daemon@optimus.ietf.org Mon Mar 11 11:59:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14818 for ; Mon, 11 Mar 2002 11:59:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29410 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 11:59:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28325; Mon, 11 Mar 2002 11:33:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28294 for ; Mon, 11 Mar 2002 11:33:55 -0500 (EST) Received: from dhcp240.dfw.dynamicsoft.com ([63.110.3.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13647 for ; Mon, 11 Mar 2002 11:33:51 -0500 (EST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dhcp240.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g2BGWdJ09299; Mon, 11 Mar 2002 10:32:39 -0600 Subject: Re: [Sip] Replaces and 481 From: Robert Sparks To: Alan Johnston Cc: "'SIP'" In-Reply-To: <002201c1c916$1dda6500$0c392ca6@ajohnston> References: <002201c1c916$1dda6500$0c392ca6@ajohnston> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 11 Mar 2002 10:32:39 -0600 Message-Id: <1015864359.9240.19.camel@dhcp240.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with the proposal. To extend 2. below, if routing prevents an INVITE-Replaces from reaching the endpoint that actually has the state to be replaced, the request fails. If the requester _wants_ to try a "maybe we can get lucky and find the right person anyhow" approach, they can resubmit the INVITE without the Replaces. RjS On Mon, 2002-03-11 at 10:02, Alan Johnston wrote: > All, > > I'd like to discuss an open issue in the current Replaces draft > (http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-00.txt) > in Section 5.1: > > " If no match is found, the UAS MUST ignore the header and process the > INVITE normally. > > OPEN ISSUE: If no match is found, should the UAS ignore the > header and process normally, or return a 481?" > > The current use of Replaces in the Transfer and Service Examples draft > uses the current behavior that the header is ignored if no dialog > matches. Also, since no Require: replaces header is present in the > current call flows, a UA that does not understand Replaces also just > ignores the header. > > This becomes an issue in attended transfer in the presence of forking or > misrouting, in which the triggered INVITE with the Replaces header may > reach the wrong endpoint. The current solution to this is to use the > Accept-Contact only=true header so that the wrong endpoint will reject > the INVITE rather than accepting it. However, the requirement on a UAS > to reject a request in which the Accept-Contact only=true header is > present is only a SHOULD. Also, a Require: prefs would be needed in the > triggered INVITE to make certain that the UAS understands the > Accept-Contact header. This could cause an attended transfer to fail > with a 420 response because the UAS does not support Caller Prefs when > in fact it may support Replaces and the transfer should succeed. > > An alternative is to change the Replaces behavior to say that a matching > failure generates a 481 response. If the triggered INVITE with the > Replaces contained a Require: replaces header, then one of three things > will happen when a UAS receives it: > > 1. The UA does not understand Replaces and will return a 420. This > means that an attended transfer will fail, and the transferor should > fall back to the unattended transfer which does not use the Replaces > header. > > 2. The UA does understand Replaces but the dialog does not generate a > match and a 481 is returned. If this is caused by misrouting, it is an > error condition. The transferor could try sending the REFER to the > other party (see if the transfer works in the other direction). With > forking, the incorrect endpoints should all return a 481 while the > correct endpoint will return a 200 resulting in a successful transfer. > > 3. The UA does understand Replaces matches and the dialog matches and a > 200 OK is sent. The attended transfer succeeds. > > This way, the transferor knows the outcome of the transfer and each > failure suggests a fallback or course of action to resolve the problem. > > Although I am not in favor of most uses of the Require header, I like > this approach. Note that the Require: replaces would be in the > triggered INVITE only, and not in initial INVITEs. The normal option > discovery mechanisms (Allow: REFER and Supported: replaces) would be > used most of the time. > > Comments? > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.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 daemon@optimus.ietf.org Mon Mar 11 15:19:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21764 for ; Mon, 11 Mar 2002 15:19:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13166 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 15:19:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11776; Mon, 11 Mar 2002 14:52:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11741 for ; Mon, 11 Mar 2002 14:52:44 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20816 for ; Mon, 11 Mar 2002 14:52:39 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 14:52:11 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460A3FE3@ftmail> From: "Alan O'Neill" To: "'Dean Willis'" , sip@ietf.org Cc: wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: RE: [Sip] WGLC for Manyfolks draft Date: Mon, 11 Mar 2002 14:52:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi All, I am presently at IEEE but should get a chance to undertake a thorough review by the end of the week ok. -----Original Message----- From: Dean Willis [mailto:dwillis@dynamicsoft.com] Sent: 10 March 2002 22:11 To: sip@ietf.org Cc: wtm@research.att.com; Gonzalo Camarillo; jo@ipdialog.com; Rohan Mahy; brian.rosen@marconi.com Subject: [Sip] WGLC for Manyfolks draft We'd like to open discussion for working group last call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks-resource-05.t xt This is part of the "Bundle 2" group needed by 3GPP. The working group last call discussion period will close immediately after IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as possible thereafter. -- Dean Willis SIP WG Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 16:57:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26665 for ; Mon, 11 Mar 2002 16:57:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17701 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 16:57:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16290; Mon, 11 Mar 2002 16:27:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16259 for ; Mon, 11 Mar 2002 16:27:28 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25432 for ; Mon, 11 Mar 2002 16:27:22 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 11 Mar 2002 13:26:55 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Mar 2002 13:26:54 -0800 Received: from red-msg-03.redmond.corp.microsoft.com ([157.54.12.73]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 13:26:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Mar 2002 13:26:05 -0800 Message-ID: Thread-Topic: Definition of WSP Thread-Index: AcHJQ1oEdkmyuoqLRWmPxTBWdWLAPw== From: "Jinyan Su" To: X-OriginalArrivalTime: 11 Mar 2002 21:26:08.0464 (UTC) FILETIME=[5BE26500:01C1C943] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA16260 Subject: [Sip] Definition of WSP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, there, I am not sure whether this has been mentioned before. But in Section 25.1 Basic Rules, I saw this line: LWS = [*WSP CRLF] 1*WSP ; linear whitespace where WSP has never been defined. I guess it might be (SP|HT). Any possible reason that we use it without an explicit definition? Thanks. -Jinyan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 17:08:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27161 for ; Mon, 11 Mar 2002 17:08:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18822 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 17:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17005; Mon, 11 Mar 2002 16:35:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16974 for ; Mon, 11 Mar 2002 16:35:34 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25689 for ; Mon, 11 Mar 2002 16:35:24 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g2BLWlMb005531; Mon, 11 Mar 2002 16:32:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 16:34:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'sjy@microsoft.com'" , "'sip@ietf.org'" Subject: Re: [Sip] Definition of WSP Date: Mon, 11 Mar 2002 16:34:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org See rfc2234. Jonathan r --- Jonathan Rosenberg dynamicsoft jdrosen@dynamicsoft.com -----Original Message----- From: Jinyan Su To: sip@ietf.org Sent: Mon Mar 11 16:26:05 2002 Subject: [Sip] Definition of WSP Hi, there, I am not sure whether this has been mentioned before. But in Section 25.1 Basic Rules, I saw this line: LWS = [*WSP CRLF] 1*WSP ; linear whitespace where WSP has never been defined. I guess it might be (SP|HT). Any possible reason that we use it without an explicit definition? Thanks. -Jinyan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 11 23:19:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06115 for ; Mon, 11 Mar 2002 23:19:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06145 for sip-archive@odin.ietf.org; Mon, 11 Mar 2002 23:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05265; Mon, 11 Mar 2002 23:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05222 for ; Mon, 11 Mar 2002 23:00:10 -0500 (EST) Received: from smtp.huawei.com ([61.144.161.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05905 for ; Mon, 11 Mar 2002 23:00:03 -0500 (EST) Received: from x18916 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GSUD7X00.HA6 for ; Tue, 12 Mar 2002 11:47:57 +0800 Message-ID: <001901c1c978$f1ca25a0$81190b0a@huawei.com.cn> From: "Peili Xu" To: Date: Tue, 12 Mar 2002 11:49:43 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C1C9BB.FFDC9CC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [Sip] Why UAS can`t start a second offer before the session is complete?? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C1C9BB.FFDC9CC0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEFsbA0KDQogICAgVGhlIGN1cnJlbnQgYmlzIHByZXZlbnQgVUFTIGZyb20gb2ZmZXJpbmcg YSBzZWNvbmQgU0RPIG9mZmVyIGJlZm9yZSB0aGUgc2Vzc2lvbiBpcyBjb21wbHRlLg0KQnV0IGlu IHNvbWUgc2l0dWF0aW9uIHRoaXMgY2FwYWJpbGl0eSBpcyBzdWl0YWJsZS4NCkZvciBleGFtcGxl Og0KDQpTSVAgVUExICAgICAgICAgICAgICAgIE1HQw0KDQotLS0tLS1JTlZJVEUoU0RQLU8tMSkt LS0tLS0+ICAgIDtTRFAxIG9mZmVyIGEgc2VuZC9yZWN2IGNoYW5uZWwuDQoNCjwtLS0tLTE4MChT RFAtQS0xKS0tLS0tLS0tLS0gICAgO1NEUDIgYW5zd2VycyBhIHNlbmRvbmx5IGNoYW5uZWwganVz dCBmb3IgcmluZ2JhY2sNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJlY2F1c2UgTUdD IHVzZSBhbiBNUlMgdG8gc2VuZCByaW5nYmFjayB0b25lIGFuZCBwZXJoYXBzIGRvbmB0IGtub3cg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgTUdgcyBSVFAgYWRkcmVzcy4NCg0K PC0tLS0tMjAwKFNEUC1PLTIpLS0tLS0tLS0tLSAgICA7IHdoZW4gdXNlciBwaWNrIHVwIHRoZSBw aG9uZSBNR0Mgd2FudCB0byBjb25uZWN0IHRoZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBiaWRpcmVjdGlvbmFsIGNoYW5ubGUsIHNvIGl0IG9mZmVyYHMg YSBzZW5kL3JlY2VpdmUgY2hhbm5lbC4NCg0KLS0tLS0tQUNLKFNEUC1BLTIpLS0tLS0tLS0tPiAg ICA7VUExIGFuc3dlcnMgYSBzZW5kL3JlY2VpdmUgY2hhbm5lbC4gDQoNCg0KTm90ZTogaWYgdGhl IHNlY29uZCBvZmZlciBpcyBub3QgYWxsb3dlZCwgd2UgbXVzdCByZWx5IG9uIFVBMSB0byBzdGFy dCBhbm90aGVyIG9mZmVyLiBJIHRoaW5rIGxldCBNR0MgdG8gc3RhcnQgdGhlIG9mZmVyIGlzIG1v cmUgcmVhc29uYWJsZS4NCg0KQWxzbywgaW4gc3VjaCBzaXR1YXRpb24gYXMgdGhlIGNhbGxlZCBw YXJ0eSB3YW50IHRvIGNoYW5nZSBsb2NhbCBtZWRpYSBpbmZvIGFmdGVyIHRoZSBlYXJseSBtZWRp YSBpcyBlc3RhYmxpc2hlZChzdWNoIGFzIFBTVE4gZm9yd29yZGluZyBubyBhbnN3ZXIgYW5kIHNv IG9uLCB0aGUgcHJvY2VkdXJlIGlzIGFsc28gbmVlZGVkLg0KDQoNCg0K ------=_NextPart_000_0016_01C1C9BB.FFDC9CC0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yNjE0LjM1MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSwgQWxsPC9GT05UPjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgY3VycmVudCBiaXMgcHJldmVudCBVQVMgZnJvbSBvZmZlcmluZyBhIA0Kc2Vjb25k IFNETyBvZmZlciBiZWZvcmUgdGhlIHNlc3Npb24gaXMgY29tcGx0ZS48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5CdXQgaW4gc29tZSBzaXR1YXRpb24gdGhpcyBjYXBhYmlsaXR5IGlz IA0Kc3VpdGFibGUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Rm9yIGV4YW1wbGU6 PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNJUCAN ClVBMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCk1HQzwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4tLS0tLS1JTlZJVEUoU0RQLU8t MSktLS0tLS0mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDtTRFAxIG9mZmVyIA0KYSZuYnNwO3NlbmQv cmVjdiBjaGFubmVsLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mbHQ7LS0tLS0xODAoU0RQLUEtMSktLS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7 IDtTRFAyIA0KYW5zd2VycyBhIHNlbmRvbmx5IGNoYW5uZWwganVzdCBmb3IgcmluZ2JhY2s8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGJlY2F1c2UgTUdDIHVzZSBhbiBNUlMgdG8gc2VuZCByaW5nYmFjayB0b25lIGFuZCAN CnBlcmhhcHMgZG9uYHQga25vdyAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgTUdgcyBSVFAgYWRkcmVzcy48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+Jmx0Oy0tLS0tMjAwKFNEUC1PLTIpLS0tLS0tLS0tLSZuYnNw OyZuYnNwOyZuYnNwOyA7IHdoZW4gdXNlciANCnBpY2sgdXAgdGhlIHBob25lIE1HQyB3YW50IHRv IGNvbm5lY3QgdGhlICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJpZGlyZWN0aW9uYWwgY2hhbm5sZSwgc28gaXQgb2ZmZXJgcyBh IA0Kc2VuZC9yZWNlaXZlIGNoYW5uZWwuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tLUFDSyhTRFAtQS0yKS0tLS0tLS0tLSZndDsmbmJzcDsm bmJzcDsmbmJzcDsgO1VBMSBhbnN3ZXJzIA0KYSBzZW5kL3JlY2VpdmUgY2hhbm5lbC4gPC9GT05U PjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5Ob3RlOiBpZiB0aGUgc2Vjb25kIG9mZmVyIGlzIG5vdCBhbGxvd2VkLCB3ZSBtdXN0 IHJlbHkgb24gVUExIA0KdG8gc3RhcnQgYW5vdGhlciBvZmZlci4gSSB0aGluayBsZXQgTUdDIHRv IHN0YXJ0IHRoZSBvZmZlciBpcyBtb3JlIA0KcmVhc29uYWJsZS48L0ZPTlQ+PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QWxzbywgaW4gc3VjaCBzaXR1YXRpb24g YXMgdGhlIGNhbGxlZCBwYXJ0eSB3YW50IHRvIGNoYW5nZSANCmxvY2FsIG1lZGlhIGluZm8gYWZ0 ZXIgdGhlIGVhcmx5IG1lZGlhIGlzIGVzdGFibGlzaGVkKHN1Y2ggYXMgUFNUTiBmb3J3b3JkaW5n IG5vIA0KYW5zd2VyIGFuZCBzbyBvbiwgdGhlIHByb2NlZHVyZSBpcyBhbHNvIG5lZWRlZC48L0ZP TlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0016_01C1C9BB.FFDC9CC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 03:55:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18118 for ; Tue, 12 Mar 2002 03:55:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28012 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 03:55:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26353; Tue, 12 Mar 2002 03:15:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26322 for ; Tue, 12 Mar 2002 03:15:42 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17620 for ; Tue, 12 Mar 2002 03:15:39 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA01745; Tue, 12 Mar 2002 09:14:55 +0100 (MET) Subject: Re: [Sip] WGLC for Manyfolks draft To: "Dean Willis" Cc: , , "Gonzalo Camarillo" , , "Rohan Mahy" , Date: Tue, 12 Mar 2002 09:14:52 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/12/2002 09:14:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Dean, The current manyfolks draft is based on SDP for the session description. Is it foreseen to create an equivalent draft for SDPng (XML based) ? Best regards Juan Carlos "Dean Willis" @ietf.org on 10/03/2002 23:11:04 Sent by: sip-admin@ietf.org To: cc: , "Gonzalo Camarillo" , , "Rohan Mahy" , Subject: [Sip] WGLC for Manyfolks draft We'd like to open discussion for working group last call on: http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks-resource-05.t xt This is part of the "Bundle 2" group needed by 3GPP. The working group last call discussion period will close immediately after IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as possible thereafter. -- Dean Willis SIP WG Co-Chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 04:30:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18408 for ; Tue, 12 Mar 2002 04:30:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29908 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 04:30:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28687; Tue, 12 Mar 2002 04:01:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28658 for ; Tue, 12 Mar 2002 04:01:34 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18199 for ; Tue, 12 Mar 2002 04:01:26 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2C91eZ16718 for ; Tue, 12 Mar 2002 11:01:40 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 11:01:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 11:01:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Mar 2002 11:01:27 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790D0@esebe019.NOE.Nokia.com> Thread-Topic: Behaviour of a UAC on timeout Thread-Index: AcHJpH5fqVjdLaT9RRWEIENP/sAGcA== To: X-OriginalArrivalTime: 12 Mar 2002 09:01:28.0017 (UTC) FILETIME=[7EACFC10:01C1C9A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA28659 Subject: [Sip] Behaviour of a UAC on timeout Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Section 12.2.1.2 says "The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout this is treated as a 408 (Request Timeout) response. 1999" then it goes on to say "A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) 2008 For INVITE initiated dialogs, terminating the dialog consists of sending a BYE. 2009" So, do we treat it as a 408 or terminate the dialog with a BYE? No where in the spec does it say that a if the UAC receives a 408 to an INVITE, it should terminate the dialog. Regards, Hisham Khartabil _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 04:36:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18485 for ; Tue, 12 Mar 2002 04:36:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA00315 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 04:36:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28948; Tue, 12 Mar 2002 04:07:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28921 for ; Tue, 12 Mar 2002 04:07:48 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18245 for ; Tue, 12 Mar 2002 04:07:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2C97tZ22555 for ; Tue, 12 Mar 2002 11:07:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 11:07:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 11:07:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Behaviour of a UAC on timeout Date: Tue, 12 Mar 2002 11:07:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790D1@esebe019.NOE.Nokia.com> Thread-Topic: Behaviour of a UAC on timeout Thread-Index: AcHJpH5fqVjdLaT9RRWEIENP/sAGcAAAJbwQ To: X-OriginalArrivalTime: 12 Mar 2002 09:07:41.0971 (UTC) FILETIME=[5D91D630:01C1C9A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA28922 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I've answered my own question. This is for requests within a dialog. Regards, Hisham > -----Original Message----- > From: Khartabil Hisham (NMP/Helsinki) > Sent: Tuesday, March 12, 2002 11:01 AM > To: sip@ietf.org > Subject: [Sip] Behaviour of a UAC on timeout > > > Section 12.2.1.2 says > > "The UAC will receive responses to the request from the transaction > layer. If the client transaction returns a timeout this is > treated as a 408 (Request Timeout) response. 1999" > > then it goes on to say > > "A UAC SHOULD also terminate a dialog if no response > at all is received for the request (the client transaction > would inform the TU about the timeout.) 2008 > For INVITE initiated dialogs, terminating the dialog consists > of sending a BYE. 2009" > > So, do we treat it as a 408 or terminate the dialog with a > BYE? No where in the spec does it say that a if the UAC > receives a 408 to an INVITE, it should terminate the dialog. > > Regards, > Hisham Khartabil > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 08:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20811 for ; Tue, 12 Mar 2002 08:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA10008 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 08:03:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08065; Tue, 12 Mar 2002 07:43:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05979 for ; Mon, 11 Mar 2002 23:12:32 -0500 (EST) Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06046 for ; Mon, 11 Mar 2002 23:12:20 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id g2C4AAP22474 for ; Tue, 12 Mar 2002 09:40:11 +0530 (IST) Received: from wipro.com ([10.111.17.241]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GSUEBK00.H0H; Tue, 12 Mar 2002 09:41:44 +0530 Message-ID: <3C8D819C.D6B9510D@wipro.com> Date: Tue, 12 Mar 2002 09:48:36 +0530 From: "Pramod Vishnu Patil" Organization: Wipro X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mgovind@hss.hns.com CC: Tom_Gray@Mitel.COM, sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Re: [Sip] Line folding of Sip Headers References: <65256B79.004982E9.00@sampark.hss.hns.com> Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-0bbfd608-356e-11d6-a942-00b0d0d06be8" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-0bbfd608-356e-11d6-a942-00b0d0d06be8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I strongly agree with Mahesh. Line folding is not a useful future. I feel line folding actually will harm the readability of the message if the viewer is using text wrap feature. I think it should be left to the viewer how long lines should be shown in the editor. -Pramod. mgovind@hss.hns.com wrote: > HI, > > But how will line folding help for much readability.I think ASN is a > different case. > In the case of text based messages ,the cost of implementing a parser > which can handle line folding is > obviously very high compared to is usefulness.Also if somebody wants to > open a message a using a text editor, > most text editors today will fold it and show it. > > regards > mahesh > > Tom_Gray@Mitel.COM on 03/11/2002 06:53:22 PM > > To: Mahesh Govind/HSSBLR, Tom_Gray@Mitel.COM > cc: sip@ietf.org, sip-implementors@cs.columbia.edu > > Subject: Re: [Sip] Line folding of Sip Headers > > From: Tom Gray@MITEL on 03/11/2002 08:23 AM > > It has always been my impression that human readability is seen as a major > advantage of text-based messaging. ASN.1 is criticised since it requires > special > analysers to interpret messages and that this both adds expense and delays > development. > > mgovind@hss.hns.com on 03/11/2002 03:46:39 AM > > To: sip@ietf.org, sip-implementors@cs.columbia.edu > cc: (bcc: Tom Gray/Kan/Mitel) > > Subject: [Sip] Line folding of Sip Headers > > Hi, > > I will be thankful if you can clarify my doubt regarding allowing line > folding in SipHeaders. > > In real world senarios ,whether any body is sending a linefolded Sip > message , because > most part of a sip message will be generated not by hand . > If our policy is to to keep it simple .... , why are we allowing line > folding and making implementations more > complex.Why cant we have a complete signaling without line folding. > If I am wrong please correct me. > regards > > mahesh@Hughes Software systems > > This message is proprietary to Hughes Software Systems Limited (HSS) and is > intended solely for the use of the individual to whom it is addressed. It > may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing > the contents of this message. HSS accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ------=_NextPartTM-000-0bbfd608-356e-11d6-a942-00b0d0d06be8 Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-0bbfd608-356e-11d6-a942-00b0d0d06be8-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 10:37:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24708 for ; Tue, 12 Mar 2002 10:37:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19492 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 10:37:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17339; Tue, 12 Mar 2002 10:07:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17312 for ; Tue, 12 Mar 2002 10:07:14 -0500 (EST) Received: from dhcp240.dfw.dynamicsoft.com ([63.110.3.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24072 for ; Tue, 12 Mar 2002 10:07:11 -0500 (EST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by dhcp240.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g2CF6QU01701 for ; Tue, 12 Mar 2002 09:06:26 -0600 From: Robert Sparks To: sip@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 12 Mar 2002 09:06:26 -0600 Message-Id: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Status of REFER Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit First - many thanks to those people who found the time to comment on the current REFER draft during the bis-storm. The feedback I received indicates that we should alter the plan discussed in SLC. Specifically, we should not advance the REFER draft without a concrete mechanism for securing information passed from the referror through the referree to the refer target). I'm working on a couple of mechanisms now. The draft also needs to be realigned with the new SIP and SIP-events RFCs. For instance, the ;cseq= parameter should be replaced with the more general ;id= parameter in events. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 10:53:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25343 for ; Tue, 12 Mar 2002 10:53:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20083 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 10:53:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18109; Tue, 12 Mar 2002 10:24:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18073 for ; Tue, 12 Mar 2002 10:24:28 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24308 for ; Tue, 12 Mar 2002 10:24:22 -0500 (EST) From: ssundaragopalan@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g2CF2WH06813 for ; Tue, 12 Mar 2002 20:32:32 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B7A.0053B372 ; Tue, 12 Mar 2002 20:44:14 +0530 X-Lotus-FromDomain: HSSBLR To: ssundaragopalan@hss.hns.com cc: "'sip@ietf.org'" Message-ID: <65256B7A.0053B2F8.00@sampark.hss.hns.com> Date: Tue, 12 Mar 2002 20:44:12 +0530 Subject: [Sip] SIP DNS usage issues (draft-ietf-sip-srv-06) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org hi all, the issues 1 and 3 listed below seems to be unclear from the draft. I found from the mailing list that, these issues are still not clarified by any one. can some one clarify these issues..............?? thnx and regards, srikanth Boris Perlov on 03/04/2002 12:59:22 PM To: "'sip@ietf.org'" cc: (bcc: Srikanth Sundaragopalan/HSSBLR) Subject: [Sip] SIP DNS usage issues (draft-ietf-sip-srv-06) Hello, I found following issues not clear in the SIP-SRV draft 06. Please advice what procedure should be applied. 1. In client transaction DNS usage, it is not clear if all records, returned by a NAPTR query, should be used in case of consequent procedure failure. NAPTR query output may include multiple records for the same domain. After choosing the best (order & preference) NAPTR record and in case of consequent procedure failure (e.g. sending message failure), should next NAPTR record be used? 2. In client transaction IP & port resolution procedure - paragraph 4.2, the draft-ietf-sip-srv-06 specifies that "...If no SRV records were found, the client performs an A or AAAA record lookup of the domain name.". How domain name will be determinate in case SRV lookup where applied on SRV host name, returned by previous NAPTR procedure? Will it be correct to use returned by NAPTR SRV name for the A/AAAA DNS query? 3. Although it can be guessed but it may be good to specify what port number should be used in case A/AAAA DNS query, applied as a result of SRV query failure, succeed. That because SRV query should be applied when port number was unspecified. Thanks, Boris Perlov RADVISION _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 14:01:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01730 for ; Tue, 12 Mar 2002 14:01:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02403 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 14:01:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01129; Tue, 12 Mar 2002 13:44:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01098 for ; Tue, 12 Mar 2002 13:44:23 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00930 for ; Tue, 12 Mar 2002 13:44:19 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GSV00701IP2AO@firewall.wcom.com> for sip@ietf.org; Tue, 12 Mar 2002 18:43:50 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GSV005H2IP2S7@firewall.wcom.com>; Tue, 12 Mar 2002 18:43:50 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GSV00H01IOVBX@pmismtp01.wcomnet.com>; Tue, 12 Mar 2002 18:43:49 +0000 (GMT) Received: from ajohnston ([166.38.62.100]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GSV00FH6IOI33@pmismtp01.wcomnet.com>; Tue, 12 Mar 2002 18:43:32 +0000 (GMT) Date: Tue, 12 Mar 2002 12:43:21 -0600 From: Alan Johnston Subject: RE: [Sip] Status of REFER In-reply-to: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> To: "'Robert Sparks'" , sip@ietf.org Message-id: <000f01c1c9f5$c960a850$20232aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert, I'm confused about this. We decided a while back to remove a REFER specific security scheme in favor of a more general SIP security approach. Now that we have the general SIP security scheme in bis, you are suggesting that we have to add a REFER specific security scheme back in? This makes no sense. Also, I feel that this is a specific case of the more general problem of how to transport and pass around an "authorization token" for want of a better description in SIP. It could authorize a transfer, a call back through a gateway, a one-time use of a special SIP service, etc, as briefly mentioned in the Multiparty Framework document. I am in favor of solving this general problem, not inventing a REFER specific approach (again) which may or may not work for the more general case. REFER is already way, way, way behind schedule - lets not delay any further by wading into another security quagmire - please. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Robert Sparks > Sent: Tuesday, March 12, 2002 9:06 AM > To: sip@ietf.org > Subject: [Sip] Status of REFER > > > First - many thanks to those people who found the time to > comment on the current REFER draft during the bis-storm. > > The feedback I received indicates that we should alter the > plan discussed in SLC. Specifically, we should not advance > the REFER draft without a concrete mechanism for securing > information passed from the referror through the referree > to the refer target). I'm working on a couple of mechanisms now. > > The draft also needs to be realigned with the new SIP and > SIP-events RFCs. For instance, the ;cseq= parameter should > be replaced with the more general ;id= parameter in events. > > > RjS > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 14:46:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03839 for ; Tue, 12 Mar 2002 14:46:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04985 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 14:46:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03334; Tue, 12 Mar 2002 14:18:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29054 for ; Tue, 12 Mar 2002 13:04:37 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29489 for ; Tue, 12 Mar 2002 13:04:34 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA12009 for ; Tue, 12 Mar 2002 11:04:35 -0700 (MST)] Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA26121 for ; Tue, 12 Mar 2002 11:04:34 -0700 (MST)] Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 12 Mar 2002 11:04:34 -0700 Message-ID: <93BB8E551159D5119AFD0002B32C28DA01B71506@az10exm05.sat.mot.com> From: Hall Bill-P26432 To: "'sip@ietf.org'" Date: Tue, 12 Mar 2002 11:04:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP ABNF Grammar bugs? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org SIP Spec Rep, I have appreciated all of the SIP ABNF grammar improvements over the last few releases. Thanks! I have a SIP parser that operates by interpreting the grammar almost exactly as specified in the spec (bis-09). However, if I follow the grammar exactly, I am unable to properly parse some of the supposedly correctly formatted "SIP Test Messages" files (http://www.cs.columbia.edu/~hgs/sip/sipit/testmsg.html ). In particular, 1) Commentary in the spec states that HCOLON allows whitespace, but no line break, before the colon. However, in file test1.txt a Call-ID header is specified as "CaLl-Id:0ha0isndaksdj@10.1.1.1" (a line break before the colon). To get the file to parse (assuming it is correct), I changed the grammar definition of HCOLON from HCOLON = *( SP / HTAB ) ":" SWS to HCOLON = SWS ":" SWS 2) I believe the grammar is missing optional WSP (whitespace) between the body of a message-header and the trailing CRLF. In file test1.txt the "v:" header ends with ";hidden". To get the file to parse I changed the grammar definition of message-header from message-header = (Accept / Accept-Encoding ... / WWW-Authenticate / extension-header) CRLF to message-header = (Accept / Accept-Encoding ... / WWW-Authenticate / extension-header) *WPS CRLF <-- note the *WPS 3) There seems to be missing whitespace before delay in the Timestamp header definition. I changed the Timestamp definition from Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ delay ] to Timestamp = "Timestamp" HCOLON 1*(DIGIT) [ "." *(DIGIT) ] [ SWS delay ] <-- note the SWS I also suggest the following changes to the grammar to aid folks who are parsing SIP based solely on the grammar definition: 1) Commentary states that a URI must be represented as a name-addr instead of an addr-spec if it contains certain special chars (e.g., ";"). The grammar does not enforce this, but it could. The definitions for name-addr and addr-spec allow the same characters in the URI. The definition for addr-spec should not allow the special characters. name-addr could be defined as: name-addr = [ display-name ] LAQUOT special-addr-spec RAQUOT where the definition of special-addr-spec does allow the special characters. 2) Do not make choices optional as in foo = bar / baz / [boo] (where [boo] is an optional choice). When bar, baz, and boo are NOT present in a parse string, this style of rule allows foo to match null instead of failing. Optional choices are used in rules such as dig-resp, ainfo, and digest-cln. Similarly, in the following definitions srvr is a redundantly optional choice: authority = srvr / reg-name srvr = [ [ userinfo "@" ] hostport ] and srvr will always match something (possibly null). I changed the definition of srvr to make it no longer redundantly optional: srvr = [ userinfo "@" ] hostport 3) Similarly, do not allow elements that are already optional using brackets (e.g., "[ display-name ]") match zero-or-more elements ("*" notation) since this allows the optional element to always parse by matching null. For instance, display-name = *(token LWS)/ quoted-string should be: display-name = +(token LWS)/ quoted-string 4) Do not allow any but the last choice in an alternative match the "generic" or "extension" case since these general cases always match the "specific" cases. For instance, m-type can be a discrete-type or a composite-type: m-type = discrete-type / composite-type Both a discrete-type and composite-type can be an extension-token: discrete-type = "text" / "image" / "audio" / "video" / "application" / extension-token composite-type = "message" / "multipart" / extension-token If the m-type is "multipart" in a parse string, then this will match as a discrete-type instead of a composite-type because it will match as a discrete-type extension-token. I would define m-type as m-type = discrete-type / composite-type / extension-token and remove extension-token from the definition of discrete-type and composite-type. 5) When a choice, A, matches a subset of another choice, B, always list A first. For example, a telephone-subscriber without a password is just a special form of a user. When userinfo is defined as: userinfo = [ user / telephone-subscriber [ ":" password ]] something that looks like a telephone-subscriber will match as a user. I change the rule to: userinfo = [ telephone-subscriber [ ":" password ] / user ] Similarly, since host matches a subset of token, I changed: gen-value = token / host / quoted-string to: gen-value = host / token / quoted-string For similar reasons I changed: codings = content-coding / "*" to: codings = "*" / content-coding extension-token = ietf-token / x-token to: extension-token = x-token / ietf-token host = hostname / IPv4address / IPv6reference to: host = IPv4address / hostname / IPv6reference hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] to: hexpart = "::" [ hexseq ] / hexseq "::" [ hexseq ] / hexseq Also, since iana-token is a proper subset of extension-token, then m-subtype, which is defined as: m-subtype = extension-token / iana-token will always match extension-token and never match iana-token. iana-token seems useless. 6) To better allow lookahead to differentiate alternatives I changed IPv6address = hexpart [ ":" IPv4address ] to: IPv6address = hexpart ":" IPv4address / hexpart 7) An accept-range can end in a semicolon-separated list of accept-params and m-parameters. How are accept-params and m-parameters distinguished? 8) To maintain parallelism with the other dig-resp elements that give names to their parameter values, I suggest changing auth-param = auth-param-name EQUAL ( token / quoted-string ) to auth-param = auth-param-name EQUAL auth-param-value auth-param-value = token / quoted-string Similarly, the value portion for the following productions could be given names: info-param transport-param user-param handling-param domain opaque stale algorithm Timestamp via-received Note that production rules such as: method-param = "method=" Method ttl-param = "ttl=" ttl maddr-param = "maddr=" host don't follow the xyz-param = "xyz=" xyz-param-value pattern, but their param values can be referred to by name (Method, ttl, and host). 9) Why can't media-range: media-range = ( "*/*" / ( m-type SLASH "*" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) be defined as media-range = ( m-type SLASH m-subtype ) *( SEMI m-parameter ) since m-type and m-subtype can both match "*"? I'd appreciate knowing where I have gone off the rails in any of the above analysis/suggestions. Thanks, -- Bill Hall Email: P26432@email.mot.com Motorola Voice: 480-732-2292 2501 S. Price Rd. Page: 1-800-759-8352 Chandler, AZ 85248 pin 1367646 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 15:06:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04690 for ; Tue, 12 Mar 2002 15:06:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06979 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 15:06:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04747; Tue, 12 Mar 2002 14:40:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04716 for ; Tue, 12 Mar 2002 14:40:56 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03622 for ; Tue, 12 Mar 2002 14:40:47 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2CJekh00639; Tue, 12 Mar 2002 13:40:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CJekF23269; Tue, 12 Mar 2002 13:40:46 -0600 (CST) Received: from lmf.ericsson.se (rmt160115.am.ericsson.se [138.85.160.115]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA05854; Tue, 12 Mar 2002 13:40:44 -0600 (CST) Message-ID: <3C8E5A36.749FE60B@lmf.ericsson.se> Date: Tue, 12 Mar 2002 21:42:46 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peili Xu CC: sip@ietf.org Subject: Re: [Sip] Why UAS can`t start a second offer before the session is complete?? References: <001901c1c978$f1ca25a0$81190b0a@huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, the UAS can send another offer before the session gets established. But this has to be sent in an UPDATE, not in the 200 OK. Gonzalo Peili Xu wrote: > > Hi, All > > The current bis prevent UAS from offering a second SDO offer > before the session is complte. > But in some situation this capability is suitable. > For example: > > SIP UA1 MGC > > ------INVITE(SDP-O-1)------> ;SDP1 offer a send/recv channel. > > <-----180(SDP-A-1)---------- ;SDP2 answers a sendonly channel just > for ringback > because MGC use an MRS to send ringback > tone and perhaps don`t know the MG`s > RTP address. > > <-----200(SDP-O-2)---------- ; when user pick up the phone MGC want > to connect the > bidirectional channle, so it offer`s a send/receive channel. > > ------ACK(SDP-A-2)---------> ;UA1 answers a send/receive channel. > > > Note: if the second offer is not allowed, we must rely on UA1 to start > another offer. I think let MGC to start the offer is more reasonable. > > Also, in such situation as the called party want to change local media > info after the early media is established(such as PSTN forwording no > answer and so on, the procedure is also needed. > > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Tue Mar 12 16:20:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08175 for ; Tue, 12 Mar 2002 16:20:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13254 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 16:20:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12176; Tue, 12 Mar 2002 16:02:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12145 for ; Tue, 12 Mar 2002 16:02:03 -0500 (EST) Received: from relay3.nyc2.aens.net (relay3.nyc2.attens.net [63.240.1.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07175 for ; Tue, 12 Mar 2002 16:02:00 -0500 (EST) Received: from email.masconit.com (email.masconit.com [12.107.104.100]) by relay3.nyc2.aens.net (8.11.6/8.11.6) with ESMTP id g2CL1s612121; Tue, 12 Mar 2002 21:01:54 GMT Received: from RANJIT (12.107.104.95 [12.107.104.95]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFHM0XF1; Tue, 12 Mar 2002 15:01:54 -0600 Reply-To: From: "Ranjit Avasarala" To: "'Gonzalo Camarillo'" , "'Peili Xu'" Cc: Subject: RE: [Sip] Why UAS can`t start a second offer before the session is complete?? Date: Tue, 12 Mar 2002 15:06:08 -0600 Message-ID: <000201c1ca09$bbf497d0$9800000a@RANJIT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C8E5A36.749FE60B@lmf.ericsson.se> Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit but I feel UPDATE should be sent only when UAS wants to modify some session parameters. Regards Ranjit -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Tuesday, March 12, 2002 1:43 PM To: Peili Xu Cc: sip@ietf.org Subject: Re: [Sip] Why UAS can`t start a second offer before the session is complete?? Hello, the UAS can send another offer before the session gets established. But this has to be sent in an UPDATE, not in the 200 OK. Gonzalo Peili Xu wrote: > > Hi, All > > The current bis prevent UAS from offering a second SDO offer > before the session is complte. > But in some situation this capability is suitable. > For example: > > SIP UA1 MGC > > ------INVITE(SDP-O-1)------> ;SDP1 offer a send/recv channel. > > <-----180(SDP-A-1)---------- ;SDP2 answers a sendonly channel just > for ringback > because MGC use an MRS to send ringback > tone and perhaps don`t know the MG`s > RTP address. > > <-----200(SDP-O-2)---------- ; when user pick up the phone MGC want > to connect the > bidirectional channle, so it offer`s a send/receive channel. > > ------ACK(SDP-A-2)---------> ;UA1 answers a send/receive channel. > > > Note: if the second offer is not allowed, we must rely on UA1 to start > another offer. I think let MGC to start the offer is more reasonable. > > Also, in such situation as the called party want to change local media > info after the early media is established(such as PSTN forwording no > answer and so on, the procedure is also needed. > > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 12 16:40:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08904 for ; Tue, 12 Mar 2002 16:40:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14885 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 16:40:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13340; Tue, 12 Mar 2002 16:21:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13308 for ; Tue, 12 Mar 2002 16:21:51 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08200 for ; Tue, 12 Mar 2002 16:21:47 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2CLLhh22995; Tue, 12 Mar 2002 15:21:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2CLLgX12135; Tue, 12 Mar 2002 15:21:42 -0600 (CST) Received: from lmf.ericsson.se (rmt160115.am.ericsson.se [138.85.160.115]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA15388; Tue, 12 Mar 2002 15:21:40 -0600 (CST) Message-ID: <3C8E71DE.503DBD86@lmf.ericsson.se> Date: Tue, 12 Mar 2002 23:23:42 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ranjitka@email.masconit.com CC: "'Peili Xu'" , sip@ietf.org Subject: Re: [Sip] Why UAS can`t start a second offer before the session is complete?? References: <000201c1ca09$bbf497d0$9800000a@RANJIT> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In the example given below the media stream will become sendrecv... In this case your UPDATE will change the direction attribute of the stream. Gonzalo Ranjit Avasarala wrote: > > but I feel UPDATE should be sent only when UAS wants to modify some session > parameters. > > Regards > Ranjit > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, March 12, 2002 1:43 PM > To: Peili Xu > Cc: sip@ietf.org > Subject: Re: [Sip] Why UAS can`t start a second offer before the session > is complete?? > > Hello, > > the UAS can send another offer before the session gets established. But > this has to be sent in an UPDATE, not in the 200 OK. > > Gonzalo > > Peili Xu wrote: > > > > Hi, All > > > > The current bis prevent UAS from offering a second SDO offer > > before the session is complte. > > But in some situation this capability is suitable. > > For example: > > > > SIP UA1 MGC > > > > ------INVITE(SDP-O-1)------> ;SDP1 offer a send/recv channel. > > > > <-----180(SDP-A-1)---------- ;SDP2 answers a sendonly channel just > > for ringback > > because MGC use an MRS to send ringback > > tone and perhaps don`t know the MG`s > > RTP address. > > > > <-----200(SDP-O-2)---------- ; when user pick up the phone MGC want > > to connect the > > bidirectional channle, so it offer`s a send/receive channel. > > > > ------ACK(SDP-A-2)---------> ;UA1 answers a send/receive channel. > > > > > > Note: if the second offer is not allowed, we must rely on UA1 to start > > another offer. I think let MGC to start the offer is more reasonable. > > > > Also, in such situation as the called party want to change local media > > info after the early media is established(such as PSTN forwording no > > answer and so on, the procedure is also needed. > > > > > > > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Tue Mar 12 18:06:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11433 for ; Tue, 12 Mar 2002 18:06:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21899 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 18:06:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20096; Tue, 12 Mar 2002 17:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20065 for ; Tue, 12 Mar 2002 17:39:50 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10721 for ; Tue, 12 Mar 2002 17:39:46 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 0F8A61E030 for ; Tue, 12 Mar 2002 17:39:50 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA06782; Tue, 12 Mar 2002 17:39:47 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA02897; Tue, 12 Mar 2002 17:39:15 -0500 (EST) Date: Tue, 12 Mar 2002 17:39:15 -0500 (EST) Message-Id: <200203122239.RAA02897@fish.research.att.com> To: sip@ietf.org Subject: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Gonzalo wrote: > A PRACK for a 1xx response that contained an answer can contain an offer > (as stated in the draft), because the UAS will not generate an UPDATE > until it receives the PRACK... therefore, in that situation, there is > not a chance of having a glare condition... it is OK as it is specified. I'm still a little confused about this. I don't see where the restriction is written that the UAS MUST NOT generate a new offer until its answer is acknowledged -- only that it send the answer before a new offer. There are four separate drafts that interact in making the rules: in offer-answer-02, section 8 At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. ... in 2543bis-09, section 13.2.1 If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. ... in 100rel-06, section 5 If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response. ... If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK. in update-01, section 6.1.1 ... for the callee: If the UPDATE is being sent before the completion of the INVITE transaction, and the initial INVITE contained an offer, the UPDATE annot be sent unless the callee has generated an answer in a reliable provisional response, and has not sent or received other UPDATE requests containing offers that have not been answered. It seems to me that a perfectly valid sequence is --- INVITE (offer) ---> <-- 183 (answer) ------ --- PRACK (offer) \ <-- UPDATE (offer) ---- \-- and at this point there is glare. The 100rel draft now requires the UAS to respond to the offer in the PRACK with an answer in the 200 (OK). The nearest text which is close to this case is update-01 section 6.2.1 If an UPDATE is received that contains an offer, and the UAS has generated an offer (presumably in an UPDATE of its own) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response. This text in 6.2.1 should be generalized to cover this additional glare case, by requiring the UAC to respond to an UPDATE request with a 491 if it has an outstanding offer pending in a PRACK. I'd suggest: If an UPDATE is received that contains an offer, and the receiver has generated an offer to which it has not yet received an answer, the UPDATE MUST be rejected with a 491 response. Also, the UAS on receiving the 491 does not need to follow the procedures in bis-09 section 14.1 for this case and can re-send the UPDATE immediately. However, the random delay does no real harm. An editorial nit in update-01, section 6.1.1 final paragraph should reference section 14.1 of RFC BBBB, not section 4.1. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 18:36:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12201 for ; Tue, 12 Mar 2002 18:36:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23451 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 18:36:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22514; Tue, 12 Mar 2002 18:21:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22483 for ; Tue, 12 Mar 2002 18:21:11 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11937 for ; Tue, 12 Mar 2002 18:21:07 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2CNKxn09023; Tue, 12 Mar 2002 18:20:59 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY57399; Tue, 12 Mar 2002 18:20:39 -0500 (EST) Message-ID: <3C8E8D47.9BB50B11@cisco.com> Date: Tue, 12 Mar 2002 18:20:39 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: sip-mib@yahoogroups.com Subject: Re:[Sip] SIP MIB Work Plan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit we need to determine the direction we want to go here. if anyone believes they have legitimate reasons for us to persue option 1, speak up now. otherwise, i expect that the mibs will be re-worked to align with the new bis RFC and the existing mib modules may or may not resemble what they do today. kevin -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, March 08, 2002 11:41 AM To: sip@ietf.org Subject: [Sip] SIP MIB Work Plan Ok, the SIP MIB document has been floating around for a while, and we've done a light WGLC on it. However, this doc reflects RFC 2543, not bis. We have two choices: 1) Work to issue a MIB for 2543, then do a revised one for the new bis RFC 2) Move straight to BIS. I don't believe I've seen a huge demand for a MIB RFC for 2543, but not everybody talks to me about this . . . So what do you people think? -- Dean -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 20:07:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13971 for ; Tue, 12 Mar 2002 20:07:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28086 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 20:07:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26807; Tue, 12 Mar 2002 19:44:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26777 for ; Tue, 12 Mar 2002 19:44:09 -0500 (EST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13614 for ; Tue, 12 Mar 2002 19:44:05 -0500 (EST) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.10.1/8.10.1) with ESMTP id g2D0hUb20821; Tue, 12 Mar 2002 17:43:30 -0700 (MST) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 17:43:29 -0700 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF02E9D9F9@srvmail.cablelabs.com> From: Jean-Francois Mule To: "'Kevin Lingle'" , sip@ietf.org Cc: sip-mib@yahoogroups.com Subject: RE: [Sip] SIP MIB Work Plan Date: Tue, 12 Mar 2002 17:43:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Kevin wrote: > otherwise, i expect that the mibs will be re-worked to > align with the new bis RFC and the existing mib modules > may or may not resemble what they do today. I'm personally inclined to do some rework on the mib modules to reflect the changes in bis. /Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 20:07:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13972 for ; Tue, 12 Mar 2002 20:07:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28091 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 20:07:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26899; Tue, 12 Mar 2002 19:46:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26868 for ; Tue, 12 Mar 2002 19:46:11 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13641; Tue, 12 Mar 2002 19:46:07 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2D0k9U03665; Tue, 12 Mar 2002 18:46:09 -0600 From: "Dean Willis" To: Cc: Date: Tue, 12 Mar 2002 18:46:00 -0600 Message-ID: <01c001c1ca28$723764a0$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP WG Agenda, IETF 53 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The current working agenda for the SIP working group meeting at IETF 53 is posted in HTML at: http://www.softarmor.com/sipwg/meets/ietf53/agenda.html. Text follows. Please note that rather than soliciting REQUESTS, we're solicting LEADERSHIP -- people listed below are hereby asked to lead discussions on the topics indicated. Let me know of any issues. And as always, the agenda is subject to change. Note the fact that every session starts with the obligatory agenda bash. -------------- SIP WG Agenda, IETF 53 ------------------------------------------------------------------------ -------- Session 1: Monday, 18Mar, 1930-2200, Salon D 1930 Agenda Bash Chairs 1940 Work Plan Chairs 2000 SIP Change Process discussion Allison Mankin draft-tsvarea-sipchange-01.txt 2020 SIP Update Method open issues Jonathan Rosenberg draft-ietf-sip-update-01.txt 2045 Manyfolks open issues Gonzalo Camarillo draft-ietf-sip-manyfolks-resource-05.txt 2105 Reason Code extension header requirements and proposal Gonzalo Camarillo draft-schulzrinne-sip-reason-01.txt 2130 Media Authorization open Issues Andreas Flemming / Bill Marshall draft-ietf-sip-call-auth-04.txt 2150 Message method Open Issues Jonathan Rosenberg draft-ietf-sip-message-01.txt 2200 Close Session 2: Wednesday, 20Mar, 1300-1500, Salon D 1300 Agenda Bash Chairs 1305 Advanced Digest Open Issues? James Undery draft-undery-sip-auth-00.txt 1340 Security Negotiation Open Issues Jari Arkko draft-arkko-sip-sec-agree-01.txt 1400 Privacy Open Issues Andreas Flemming / Bill Marshall drafts/draft-ietf-sip-privacy-04.txt 1430 Refer Open Issues Robert Sparks draft-ietf-sip-refer-02.txt 1500 Close ------------------------------------------------------------------------ -------- updated 12 Mar 2002 18:34:10 -0600 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 20:37:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14764 for ; Tue, 12 Mar 2002 20:37:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA29472 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 20:37:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28500; Tue, 12 Mar 2002 20:19:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28468 for ; Tue, 12 Mar 2002 20:19:40 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14279 for ; Tue, 12 Mar 2002 20:19:37 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2D1JZc11222; Tue, 12 Mar 2002 20:19:35 -0500 Message-Id: <200203130119.g2D1JZc11222@minotaur.nge.isi.edu> To: Kevin Lingle cc: sip@ietf.org, sip-mib@yahoogroups.com Reply-To: mankin@isi.edu Subject: Re: [Sip] SIP MIB Work Plan In-reply-to: Your message of Tue, 12 Mar 2002 18:20:39 -0500. <3C8E8D47.9BB50B11@cisco.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 12 Mar 2002 20:19:35 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org AD point-of-view: The new SIP RFC obsoletes RFC 2543, so there is good reason to rework the MIBs to align with bis. This is also a good time to start on the OAM Area's MIB process too. Normally the Management AD, Bert Wijnen, locates someone to be the OAM MIB Doctor for a WG, and he or she gives SNMP and MIB advice to the editors of the MIB, and helps shepherd the MIB to approval. I've asked Bert to start locating a MIB Doctor for SIP. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 21:38:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16735 for ; Tue, 12 Mar 2002 21:38:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA02601 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 21:39:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01222; Tue, 12 Mar 2002 21:09:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA01191 for ; Tue, 12 Mar 2002 21:09:29 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15370 for ; Tue, 12 Mar 2002 21:09:25 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2D29Gb18653; Tue, 12 Mar 2002 21:09:16 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY60196; Tue, 12 Mar 2002 21:08:55 -0500 (EST) Message-ID: <3C8EB4B7.74456BD8@cisco.com> Date: Tue, 12 Mar 2002 21:08:55 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mankin@isi.edu CC: sip@ietf.org, sip-mib@yahoogroups.com Subject: Re: [Sip] SIP MIB Work Plan References: <200203130119.g2D1JZc11222@minotaur.nge.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Allison Mankin wrote: > > AD point-of-view: > > The new SIP RFC obsoletes RFC 2543, so there is good reason > to rework the MIBs to align with bis. agreed. > > This is also a good time to start on the OAM Area's MIB process too. > Normally the Management AD, Bert Wijnen, locates someone to be > the OAM MIB Doctor for a WG, and he or she gives SNMP and MIB advice > to the editors of the MIB, and helps shepherd the MIB to approval. that would be great. > > I've asked Bert to start locating a MIB Doctor for SIP. thank you. please, let us know what bert says. kevin > > Allison -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 12 23:51:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19691 for ; Tue, 12 Mar 2002 23:51:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08578 for sip-archive@odin.ietf.org; Tue, 12 Mar 2002 23:51:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07299; Tue, 12 Mar 2002 23:25:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07268 for ; Tue, 12 Mar 2002 23:25:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18862 for ; Tue, 12 Mar 2002 23:25:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.117]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2D4Q7TE002788; Tue, 12 Mar 2002 23:26:09 -0500 (EST) Message-ID: <3C8ED4A2.647AEB90@dynamicsoft.com> Date: Tue, 12 Mar 2002 23:25:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ofir Arkin CC: sip@ietf.org Subject: Re: [Sip] To tag with 16.6 Request Forwarding References: <001101c1c865$2c213370$0a01a8c0@joshua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ofir Arkin wrote: > > Section 16.6 point 8 "Add a Via header field value": > > It is suggested that a cryptographic hash will be used for the value in > the branch parameter used for loop detection. > > The text suggests that computing a cryptographic hash of the To tag, > >From tag, Call-ID header field, the Request-URI and the CSeq header > field will be done. > > My question is the following: > When the proxy receives a request, an INVITE, the to field does not have > a tag yet...? > > Or am I am getting this wrong? An initial INVITE won't. A re-INVITE will. If its there, hash it. If its not, don't. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@ns.ietf.org Wed Mar 13 03:14:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00144 for ; Wed, 13 Mar 2002 03:14:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28420 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 03:14:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26603; Wed, 13 Mar 2002 02:39:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26564 for ; Wed, 13 Mar 2002 02:39:52 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29740; Wed, 13 Mar 2002 02:39:48 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2D7dnU05945; Wed, 13 Mar 2002 01:39:49 -0600 Message-ID: <00b601c1ca62$420b09f0$133fed0c@C1893415A> From: "Dean Willis" To: "Dean Willis" , Cc: References: <01c001c1ca28$723764a0$bb036e3f@TXDWILLIS2> Subject: Re: [Sip] SIP WG Agenda, IETF 53 Date: Wed, 13 Mar 2002 01:39:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Revised due to spelling errors. I wish I could spell. The current working agenda for the SIP working group meeting at IETF 53 is posted in HTML at: http://www.softarmor.com/sipwg/meets/ietf53/agenda.html. Text follows. Please note that rather than soliciting REQUESTS, we're solicting LEADERSHIP -- people listed below are hereby asked to lead discussions on the topics indicated. Let me know of any issues. And as always, the agenda is subject to change. Note the fact that every session starts with the obligatory agenda bash. -------------- SIP WG Agenda, IETF 53 ------------------------------------------------------------------------ Session 1: Monday, 18Mar, 1930-2200, Salon D 1930 Agenda Bash Chairs 1940 Work Plan Chairs 2000 SIP Change Process discussion Allison Mankin draft-tsvarea-sipchange-01.txt 2020 SIP Update Method open issues Jonathan Rosenberg draft-ietf-sip-update-01.txt 2045 Manyfolks open issues Gonzalo Camarillo draft-ietf-sip-manyfolks-resource-05.txt 2105 Reason Code extension header requirements and proposal Gonzalo Camarillo draft-schulzrinne-sip-reason-01.txt 2130 Media Authorization open Issues Flemming Andreasen / Bill Marshall draft-ietf-sip-call-auth-04.txt 2150 Message method Open Issues Jonathan Rosenberg draft-ietf-sip-message-01.txt 2200 Close Session 2: Wednesday, 20Mar, 1300-1500, Salon D 1300 Agenda Bash Chairs 1305 Advanced Digest Open Issues? James Undery draft-undery-sip-auth-00.txt 1340 Security Negotiation Open Issues Jari Arkko draft-arkko-sip-sec-agree-01.txt 1400 Privacy Open Issues Flemming Andreasen / Bill Marshall drafts/draft-ietf-sip-privacy-04.txt 1430 Refer Open Issues Robert Sparks draft-ietf-sip-refer-02.txt 1500 Close _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 13 09:19:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05980 for ; Wed, 13 Mar 2002 09:18:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17182 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 09:19:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15788; Wed, 13 Mar 2002 08:59:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15756 for ; Wed, 13 Mar 2002 08:59:14 -0500 (EST) Received: from sm11.texas.rr.com (sm11.texas.rr.com [24.93.35.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05150 for ; Wed, 13 Mar 2002 08:59:12 -0500 (EST) Received: from Joonslaptop (rrcs-sw-24-242-141-166.biz.rr.com [24.242.141.166]) by sm11.texas.rr.com (8.12.1/8.12.0) with SMTP id g2DDtLKW021366; Wed, 13 Mar 2002 07:55:21 -0600 Reply-To: From: "jmaeng" To: "'Kevin Lingle'" , Cc: , Subject: RE: [Sip] SIP MIB Work Plan Date: Wed, 13 Mar 2002 07:59:06 -0600 Message-ID: <000b01c1ca97$3dff2b90$a68df218@Joonslaptop> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <3C8EB4B7.74456BD8@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I knew two companies were implementing SIP MIBs. When I asked them about revising the MIBs to align with bis, they didn't have any objections. Joon > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Kevin > Lingle > Sent: Tuesday, March 12, 2002 8:09 PM > To: mankin@isi.edu > Cc: sip@ietf.org; sip-mib@yahoogroups.com > Subject: Re: [Sip] SIP MIB Work Plan > > > Allison Mankin wrote: > > > > AD point-of-view: > > > > The new SIP RFC obsoletes RFC 2543, so there is good reason > > to rework the MIBs to align with bis. > > agreed. > > > > > This is also a good time to start on the OAM Area's MIB process too. > > Normally the Management AD, Bert Wijnen, locates someone to be > > the OAM MIB Doctor for a WG, and he or she gives SNMP and MIB advice > > to the editors of the MIB, and helps shepherd the MIB to approval. > > that would be great. > > > > > I've asked Bert to start locating a MIB Doctor for SIP. > > thank you. please, let us know what bert says. > > kevin > > > > Allison > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > Kevin R. Lingle 919.392.2029 > checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ > Sometimes I think I understand everything, then I regain > consciousness. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-= > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 13 10:16:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07651 for ; Wed, 13 Mar 2002 10:16:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20442 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 10:16:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19028; Wed, 13 Mar 2002 09:53:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18997 for ; Wed, 13 Mar 2002 09:53:04 -0500 (EST) Received: from porfidio.atstake.com (porfidio.atstake.com [63.168.6.70]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07069 for ; Wed, 13 Mar 2002 09:53:01 -0500 (EST) Received: (qmail 814 invoked from network); 13 Mar 2002 14:54:48 -0000 Received: from unknown (HELO cam-relay.atstake.com) (10.1.1.30) by porfidio.atstake.com with SMTP; 13 Mar 2002 14:54:48 -0000 Received: from stake.com (unknown [10.50.1.52]) by cam-relay.atstake.com (Postfix) with SMTP id E9F1B22818 for ; Wed, 13 Mar 2002 09:52:11 -0500 (EST) Message-ID: <3C8F6804.9090706@stake.com> Date: Wed, 13 Mar 2002 14:53:56 +0000 From: Ofir Arkin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: SIP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question: Response Context Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The response context is defined under section 16.6 request forwarding: Response Context is the mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. The text does not define what exactly is stored with the response context mechanism (or it is me who did not find it). Can you please clarify that? since under 16.7 Response Processing it states that the response context will be located using a key described in section 16.6... -- Ofir Arkin Managing Security Architect @stake, Limited. http://www.atstake.com email: ofir@stake.com Tel: +44 (0) 207 495 7002 Fax: +44 (0) 207 495 7062 Mobile: +44 (0) 779 630 8632 ----------------------------- The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re transmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 13 12:28:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12135 for ; Wed, 13 Mar 2002 12:28:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29897 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 12:28:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28692; Wed, 13 Mar 2002 12:04:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28661 for ; Wed, 13 Mar 2002 12:04:01 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11294 for ; Wed, 13 Mar 2002 12:03:57 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2DH40U09266; Wed, 13 Mar 2002 11:04:00 -0600 Message-ID: <014201c1cab1$1203ddf0$133fed0c@C1893415A> From: "Dean Willis" To: Cc: "Ben Campbell" , References: <01c001c1ca28$723764a0$bb036e3f@TXDWILLIS2> <00b601c1ca62$420b09f0$133fed0c@C1893415A> Date: Wed, 13 Mar 2002 11:03:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Another nit, SIP WG Agenda, IETF 53 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems I should have asked Ben Campbell to lead the discussion on MESSAGE method, as he appears to be the active editor of that document (although Jonathan's name is first on the author list . . ., ahem ). It has been so amended in the web-posted agenda. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 13 13:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13342 for ; Wed, 13 Mar 2002 13:03:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02313 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 13:03:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01047; Wed, 13 Mar 2002 12:45:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01011 for ; Wed, 13 Mar 2002 12:44:55 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12746 for ; Wed, 13 Mar 2002 12:44:40 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2DHhsM23564; Wed, 13 Mar 2002 18:43:55 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 17:44:03 -0000 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , sip@ietf.org Cc: wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: RE: [Sip] WGLC for Manyfolks draft Date: Wed, 13 Mar 2002 17:43:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CAB6.A6E3CC50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CAB6.A6E3CC50 Content-Type: text/plain; charset="iso-8859-1" All, Two comments: 1) Section 11.1 (page 16) describes the sending of a new Offer in the 200 OK to the INVITE (after an offer/answer exchange has already completed) in order to take the media off hold: "However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in the 200 OK for the INVITE (8)." I thought we decided this was not allowed due to the glare problem (no way of rejecting the SDP in the 200 OK). Instead the UAS has to send both an UPDATE and a 200 OK (hopefully at the same time, without waiting for the response to one before sending the other). 2) It's not 100% clear which elements are specific to the 'qos' pre-condition type and which are intended to be general for all pre-condition types. status-type and strength-type seem to be general as does direction-tag when applied to the confirmation status (which direction(s) is confirmation required ?). These things would work in the same way for any new pre-condition tags as they do for qos. However, direction-tag applied to current and desired status seems to have a specific meaning related to the direction of QoS reservations. Other pre-condition types could be imagined for which a different type of status indication was required. So, perhaps they syntax for curr and des should include a generalised 'status' which in the case of qos has type direction-tag ? It's important because the behaviour on receipt of pre-conditions with an unknown pre-condition type need not be to always reject (BTW is this defined ?). A UA can deal with pre-conditions which are 'local' to the other UA even if it does not recognise the pre-condition type - namely, ask for confirmation and wait until the curr and des status for match. Regards...Mark > -----Original Message----- > From: Dean Willis [mailto:dwillis@dynamicsoft.com] > Sent: 10 March 2002 22:11 > To: sip@ietf.org > Cc: wtm@research.att.com; Gonzalo Camarillo; jo@ipdialog.com; Rohan > Mahy; brian.rosen@marconi.com > Subject: [Sip] WGLC for Manyfolks draft > > > We'd like to open discussion for working group last call on: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks > -resource-05.t > xt > > This is part of the "Bundle 2" group needed by 3GPP. > > The working group last call discussion period will close > immediately after > IETF 53, eta March 25, with the intent to move to IETF Last > Call as soon as > possible thereafter. > > -- > Dean Willis > SIP WG Co-Chair > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1CAB6.A6E3CC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] WGLC for Manyfolks draft

All,

Two comments:

1) Section 11.1 (page 16) describes the sending of a = new Offer in the 200 OK to the INVITE (after an offer/answer exchange = has already completed) in order to take the media off hold:

   "However, if B wants A to generate = local ringback, it can put the
   media stream on hold in SDP4. In this = case, B would put the media
   stream off hold by sending an offer in = the 200 OK for the INVITE (8)."

I thought we decided this was not allowed due to the = glare problem (no way of rejecting the SDP in the 200 OK). Instead the = UAS has to send both an UPDATE and a 200 OK (hopefully at the same = time, without waiting for the response to one before sending the = other).

2) It's not 100% clear which elements are specific to = the 'qos' pre-condition type and which are intended to be general for = all pre-condition types. status-type and strength-type seem to be = general as does direction-tag when applied to the confirmation status = (which direction(s) is confirmation required ?). These things would = work in the same way for any new pre-condition tags as they do for = qos.

However, direction-tag applied to current and desired = status seems to have a specific meaning related to the direction of QoS = reservations. Other pre-condition types could be imagined for which a = different type of status indication was required. So, perhaps they = syntax for curr and des should include a generalised 'status' which in = the case of qos has type direction-tag ?

It's important because the behaviour on receipt of = pre-conditions with an unknown pre-condition type need not be to always = reject (BTW is this defined ?). A UA can deal with pre-conditions which = are 'local' to the other UA even if it does not recognise the = pre-condition type - namely, ask for confirmation and wait until the = curr and des status for match.

Regards...Mark
  



> -----Original Message-----
> From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: 10 March 2002 22:11
> To: sip@ietf.org
> Cc: wtm@research.att.com; Gonzalo Camarillo; = jo@ipdialog.com; Rohan
> Mahy; brian.rosen@marconi.com
> Subject: [Sip] WGLC for Manyfolks draft
>
>
> We'd like to open discussion for working group = last call on:
>
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-m= anyfolks
> -resource-05.t
> xt
>
> This is part of the "Bundle 2" group = needed by 3GPP.
>
> The working group last call discussion period = will close
> immediately after
> IETF 53, eta March 25, with the intent to move = to IETF Last
> Call as soon as
> possible thereafter.
>
> --
> Dean Willis
> SIP WG Co-Chair
>
>
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1CAB6.A6E3CC50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 13 17:10:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21537 for ; Wed, 13 Mar 2002 17:10:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19922 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 17:11:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18098; Wed, 13 Mar 2002 16:55:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18067 for ; Wed, 13 Mar 2002 16:55:18 -0500 (EST) Received: from tpamail2.bdi.gte.com (tpamail2.bdi.gte.com [192.76.82.136]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21117 for ; Wed, 13 Mar 2002 16:55:15 -0500 (EST) From: gary.m.sacra@verizon.com Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id QAA26262 for ; Wed, 13 Mar 2002 16:54:42 -0500 (EST) Received: from smtptpa.interwan.gte.com (localhost [127.0.0.1]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id QAA15846 for ; Wed, 13 Mar 2002 16:54:19 -0500 (EST) Received: from dwsmtp01.bell-atl.com (dwmail21.interwan.gte.com [138.83.36.17]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id QAA15737 for ; Wed, 13 Mar 2002 16:54:13 -0500 (EST) To: sip@ietf.org Date: Wed, 13 Mar 2002 16:54:06 -0500 Message-ID: X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 5.0.9a |January 7, 2002) at 03/13/2002 03:54:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] SIP-H.323 Interworking Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Could someone provide me with the name(s) of the industry group(s) that are actively working on the development of a SIP-H.323 interworking function and the status of that effort? Thanks very much in advance, Gary Sacra _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 13 20:59:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27098 for ; Wed, 13 Mar 2002 20:59:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA05081 for sip-archive@odin.ietf.org; Wed, 13 Mar 2002 20:59:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04236; Wed, 13 Mar 2002 20:41:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04205 for ; Wed, 13 Mar 2002 20:41:53 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26875 for ; Wed, 13 Mar 2002 20:41:50 -0500 (EST) Message-ID: <20020314014147.80608.qmail@web11603.mail.yahoo.com> Received: from [131.107.3.92] by web11603.mail.yahoo.com via HTTP; Wed, 13 Mar 2002 17:41:47 PST Date: Wed, 13 Mar 2002 17:41:47 -0800 (PST) From: Sean Olson To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] transport=tls Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm assuming that sip:bob@domain.com;tranport=tls is not equivalent to sips:bob@domain.com but that is not spelled out anywhere in the bis-09 draft. Or am I making a false assumption? /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 00:10:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02121 for ; Thu, 14 Mar 2002 00:10:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA16322 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 00:10:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15055; Wed, 13 Mar 2002 23:49:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA15024 for ; Wed, 13 Mar 2002 23:49:13 -0500 (EST) Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01933 for ; Wed, 13 Mar 2002 23:49:10 -0500 (EST) From: Johnal123@aol.com Received: from Johnal123@aol.com by imo-d10.mx.aol.com (mail_out_v32.5.) id l.81.18f8c788 (4312) for ; Wed, 13 Mar 2002 23:48:38 -0500 (EST) Message-ID: <81.18f8c788.29c185a6@aol.com> Date: Wed, 13 Mar 2002 23:48:38 EST To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP and SCF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am trying to interwork SIP Proxy Server and Service Control Function (SCF) or SCP. This will be similar to the IN or WIN interface to SCP in PSTN. Before I define this interworking, I like to see if anyone has seen this interworking in SIP WG before? Regards, John Alayari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 00:22:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02221 for ; Thu, 14 Mar 2002 00:22:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA16747 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 00:22:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16267; Thu, 14 Mar 2002 00:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16028 for ; Thu, 14 Mar 2002 00:08:07 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02069 for ; Thu, 14 Mar 2002 00:04:53 -0500 (EST) Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2E54nU13362; Wed, 13 Mar 2002 23:04:50 -0600 Message-ID: <004201c1cb15$c56029d0$133fed0c@C1893415A> From: "Dean Willis" To: "Sean Olson" , References: <20020314014147.80608.qmail@web11603.mail.yahoo.com> Subject: Re: [Sip] transport=tls Date: Wed, 13 Mar 2002 23:04:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit As I understand it (and Jon P will shout if I'm wrong) sip:bob@domain.com;transport=tls means "send this towards bob@domain.com, using tls for the next hop" and sips:bob@domain.com means "send this to bob@domain.com, using tls for every hop until you get to domain.com" -- Dean ----- Original Message ----- From: "Sean Olson" To: Sent: Wednesday, March 13, 2002 7:41 PM Subject: [Sip] transport=tls > I'm assuming that > > sip:bob@domain.com;tranport=tls > > is not equivalent to > > sips:bob@domain.com > > but that is not spelled out anywhere in the bis-09 > draft. Or am I making a false assumption? > > /sean > > ===== > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Try FREE Yahoo! Mail - the world's greatest free email! > http://mail.yahoo.com/ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 04:26:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13272 for ; Thu, 14 Mar 2002 04:26:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11325 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 04:26:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09727; Thu, 14 Mar 2002 04:06:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA09696 for ; Thu, 14 Mar 2002 04:06:00 -0500 (EST) Received: from mmb4.vsnl.net.in (mmb4.vsnl.net.in [202.54.1.88]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12901 for ; Thu, 14 Mar 2002 04:05:56 -0500 (EST) Received: from indian (PPP-200-7-124.bng.vsnl.net.in [203.200.7.124]) by mmb4.vsnl.net.in (Postfix) with SMTP id BB26012AB1 for ; Thu, 14 Mar 2002 14:35:24 +0530 (IST) Received: from 10.10.10.7 [10.10.10.7] by indian.astha (1.61/SMTPD) at Thu, 14 Mar 02 14:25:30 India Message-ID: <001d01c1cb9b$49696d60$070a0a0a@liastha.com> X-Envelope-From: anand@asthatech.com Reply-To: anand@asthatech.com From: "anand" To: Date: Fri, 15 Mar 2002 02:30:35 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C1CBC9.63093F60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Gateway: --->> pop@GIFT - POP3/SMTP Gateway 5.5 for Exchange <<--- Subject: [Sip] query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C1CBC9.63093F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am new to sip technology. If I have to setup a sip network on LAN. = what are the component that I will need, and where can I get the = relevent free sofware if available. Kindly mail back us ASAP. Regards Anand ------=_NextPart_000_001A_01C1CBC9.63093F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
I am new to sip technology. If I have to setup a sip = network=20 on LAN. what are the component that I will need, and where can I get the = relevent free sofware if available. Kindly mail back us = ASAP.
Regards
Anand
------=_NextPart_000_001A_01C1CBC9.63093F60-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 07:37:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15812 for ; Thu, 14 Mar 2002 07:37:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA23147 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 07:37:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21725; Thu, 14 Mar 2002 07:10:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21692 for ; Thu, 14 Mar 2002 07:10:18 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15489 for ; Thu, 14 Mar 2002 07:10:15 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2EC9jh23809 for ; Thu, 14 Mar 2002 07:09:46 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Mar 2002 12:09:44 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E94B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org, "'Johnal123@aol.com'" Subject: RE: [Sip] SIP and SCF Date: Thu, 14 Mar 2002 12:09:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 3GPP TS 23.278 documents the equivalent work on CAMEL interworking to SIP. It is still work in progress, but should be available in the latest drafts area of the 3GPP website. ftp://ftp.3gpp.org/Specs/Latest-drafts/ Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Johnal123@aol.com[SMTP:Johnal123@aol.com] > Sent: 14 March 2002 4:48 > To: sip@ietf.org > Subject: [Sip] SIP and SCF > > I am trying to interwork SIP Proxy Server and Service Control Function > (SCF) > or SCP. This will be similar to the IN or WIN interface to SCP in PSTN. > Before I define this interworking, I like to see if anyone has seen this > interworking in SIP WG before? > > Regards, > > John Alayari > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 08:07:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16461 for ; Thu, 14 Mar 2002 08:07:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25068 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 08:07:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23845; Thu, 14 Mar 2002 07:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23816 for ; Thu, 14 Mar 2002 07:52:05 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16069 for ; Thu, 14 Mar 2002 07:51:50 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2ECpmj13367; Thu, 14 Mar 2002 07:51:48 -0500 Message-Id: <200203141251.g2ECpmj13367@minotaur.nge.isi.edu> To: mankin@isi.edu cc: Kevin Lingle , sip@ietf.org, sip-mib@yahoogroups.com Reply-To: mankin@isi.edu Subject: Re: [Sip] SIP MIB Work Plan In-reply-to: Your message of Tue, 12 Mar 2002 20:19:35 -0500. Date: Thu, 14 Mar 2002 07:51:48 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 08:07:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16475 for ; Thu, 14 Mar 2002 08:07:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA25083 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 08:07:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24057; Thu, 14 Mar 2002 07:55:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24028 for ; Thu, 14 Mar 2002 07:55:08 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16154 for ; Thu, 14 Mar 2002 07:55:05 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2ECt7c13384; Thu, 14 Mar 2002 07:55:07 -0500 Message-Id: <200203141255.g2ECt7c13384@minotaur.nge.isi.edu> To: sip@ietf.org Cc: Kevin Lingle , sip-mib@yahoogroups.com, dromasca@avaya.com, bwijnen@lucent.com Reply-To: mankin@isi.edu Subject: Re: [Sip] SIP MIB Work Plan In-reply-to: Your message of Tue, 12 Mar 2002 20:19:35 -0500. Date: Thu, 14 Mar 2002 07:55:07 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org [try this again] SIP MIB folks, Dan Romascanu, who recently has been the MIB doctor for the TRIP MIB, has agreed to take on the role for the SIP MIB. Thanks to Dan and Bert Wijnen. Allison _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 10:39:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19717 for ; Thu, 14 Mar 2002 10:39:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06188 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 10:39:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03148; Thu, 14 Mar 2002 10:05:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05218 for ; Thu, 14 Mar 2002 02:54:07 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12208 for ; Thu, 14 Mar 2002 02:54:04 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2E7rTi08878; Thu, 14 Mar 2002 01:53:29 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 01:53:24 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870168@va02.va.neustar.com> From: "Peterson, Jon" To: "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: RE: [Sip] transport=tls Date: Thu, 14 Mar 2002 01:53:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org According to bis09, transport=tls has been deprecated. For the purposes of backwards compatibility, the former transport=tls mechanism would be treated roughly the same way as the SIPS URI scheme; the two important differences are that transport=tls assumes TCP, and that a number of specific rules have been mandated for handling the SIPS URI that presumably wouldn't hold for transport=tls. Either of the meanings that Dean alludes to below can be expressed by the SIPS URI scheme in varying contexts. The use of SIPS in a Request-URI mandates the latter meaning (use TLS for the whole signaling path), while use in contexts such as a Record-Route, a Contact address of a registration, or in a preferred NAPTR record can suggest to the use of TLS over particular segments of a signaling path. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, March 13, 2002 9:04 PM > To: Sean Olson; sip@ietf.org > Subject: Re: [Sip] transport=tls > > > > As I understand it (and Jon P will shout if I'm wrong) > > sip:bob@domain.com;transport=tls > > means "send this towards bob@domain.com, using tls for the next hop" > > and > > sips:bob@domain.com > > means "send this to bob@domain.com, using tls for every hop until you > get to domain.com" > > -- > Dean > > ----- Original Message ----- > From: "Sean Olson" > To: > Sent: Wednesday, March 13, 2002 7:41 PM > Subject: [Sip] transport=tls > > > > I'm assuming that > > > > sip:bob@domain.com;tranport=tls > > > > is not equivalent to > > > > sips:bob@domain.com > > > > but that is not spelled out anywhere in the bis-09 > > draft. Or am I making a false assumption? > > > > /sean > > > > ===== > > Sean Olson > > > > __________________________________________________ > > Do You Yahoo!? > > Try FREE Yahoo! Mail - the world's greatest free email! > > http://mail.yahoo.com/ > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 10:40:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19808 for ; Thu, 14 Mar 2002 10:40:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06243 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 10:40:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03212; Thu, 14 Mar 2002 10:06:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03181 for ; Thu, 14 Mar 2002 10:06:05 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18703 for ; Thu, 14 Mar 2002 10:06:03 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2EF5Y904633; Thu, 14 Mar 2002 10:05:34 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA07957; Thu, 14 Mar 2002 09:05:33 -0600 (CST) Message-ID: <3C90BC2A.2080607@lucent.com> Date: Thu, 14 Mar 2002 09:05:14 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Johnal123@aol.com CC: sip@ietf.org Subject: Re: [Sip] SIP and SCF References: <81.18f8c788.29c185a6@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Johnal123@aol.com wrote: > I am trying to interwork SIP Proxy Server and Service Control Function (SCF) > or SCP. This will be similar to the IN or WIN interface to SCP in PSTN. > Before I define this interworking, I like to see if anyone has seen this > interworking in SIP WG before? Yes, please see the following I-Ds: http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-05.txt IETF also has a design team called SIN (SIP/IN) in place for this. If you need more information on this, please send me a private email and I will fill you in. The work in the above I-D is being refined as the first output of the SIN DT. Best regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 10:48:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20176 for ; Thu, 14 Mar 2002 10:48:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06831 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 10:48:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04360; Thu, 14 Mar 2002 10:24:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04329 for ; Thu, 14 Mar 2002 10:24:09 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19075 for ; Thu, 14 Mar 2002 10:24:06 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2EFNR325188; Thu, 14 Mar 2002 07:23:27 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABC84268; Thu, 14 Mar 2002 07:21:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07335; Thu, 14 Mar 2002 07:23:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15504.49268.508649.869482@thomasm-u1.cisco.com> Date: Thu, 14 Mar 2002 07:23:32 -0800 (PST) To: "Peterson, Jon" Cc: "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: RE: [Sip] transport=tls In-Reply-To: <70565611B164D511957A001083FCDD5601870168@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD5601870168@va02.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > According to bis09, transport=tls has been deprecated. For the purposes of > backwards compatibility, the former transport=tls mechanism would be treated > roughly the same way as the SIPS URI scheme; the two important differences > are that transport=tls assumes TCP, and that a number of specific rules have > been mandated for handling the SIPS URI that presumably wouldn't hold for > transport=tls. > > Either of the meanings that Dean alludes to below can be expressed by the > SIPS URI scheme in varying contexts. The use of SIPS in a Request-URI > mandates the latter meaning (use TLS for the whole signaling path), while > use in contexts such as a Record-Route, a Contact address of a registration, > or in a preferred NAPTR record can suggest to the use of TLS over particular > segments of a signaling path. So let me get this straight: an INVITE with To: sips:... should fail if somewhere along the path the next hop is protected, but just not with TLS? Somebody needs to remind why this is a Good Thing. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 10:52:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20344 for ; Thu, 14 Mar 2002 10:52:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07214 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 10:52:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05880; Thu, 14 Mar 2002 10:36:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05823 for ; Thu, 14 Mar 2002 10:36:34 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19636 for ; Thu, 14 Mar 2002 10:36:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GSY00E01Z6XNF@firewall.wcom.com> for sip@ietf.org; Thu, 14 Mar 2002 15:32:57 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GSY00CQ1Z6X29@firewall.wcom.com>; Thu, 14 Mar 2002 15:32:57 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GSY00J01Z6WBR@dgismtp02.wcomnet.com>; Thu, 14 Mar 2002 15:32:56 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GSY00DLOZ4TNQ@dgismtp02.wcomnet.com>; Thu, 14 Mar 2002 15:32:42 +0000 (GMT) Date: Thu, 14 Mar 2002 09:31:42 -0600 From: Henry Sinnreich Subject: RE: [Sip] SIP and SCF In-reply-to: <475FF955A05DD411980D00508B6D5FB00439E94B@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" , sip@ietf.org, Johnal123@aol.com Message-id: <000901c1cb6d$7ac59f10$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit How can we find the directory? "By popular request, the release-based subdirectory structure within the "Latest-drafts" folder has been removed, and the directory is now offered "flat". JMM 2001-01-26 Thanks, Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Drage, Keith (Keith) > Sent: Thursday, March 14, 2002 6:10 AM > To: sip@ietf.org; 'Johnal123@aol.com' > Subject: RE: [Sip] SIP and SCF > > > 3GPP TS 23.278 documents the equivalent work on CAMEL > interworking to SIP. It is still work in progress, but should > be available in the latest drafts area of the 3GPP website. > ftp://ftp.3gpp.org/Specs/Latest-drafts/ Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Johnal123@aol.com[SMTP:Johnal123@aol.com] > Sent: 14 March 2002 4:48 > To: sip@ietf.org > Subject: [Sip] SIP and SCF > > I am trying to interwork SIP Proxy Server and Service Control Function > (SCF) > or SCP. This will be similar to the IN or WIN interface to SCP in PSTN. > Before I define this interworking, I like to see if anyone has seen this > interworking in SIP WG before? > > Regards, > > John Alayari > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 11:10:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20772 for ; Thu, 14 Mar 2002 11:10:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08871 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 11:10:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06308; Thu, 14 Mar 2002 10:40:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06275 for ; Thu, 14 Mar 2002 10:40:26 -0500 (EST) Received: from relay1.nyc2.aens.net (relay1.nyc2.attens.net [63.240.1.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19857 for ; Thu, 14 Mar 2002 10:40:24 -0500 (EST) Received: from email.masconit.com (email.masconit.com [12.107.104.100]) by relay1.nyc2.aens.net (8.11.6/8.11.6) with ESMTP id g2EFeNf25686; Thu, 14 Mar 2002 15:40:23 GMT Received: from RANJIT (12.107.104.95 [12.107.104.95]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFHNABY6; Thu, 14 Mar 2002 09:40:22 -0600 Reply-To: From: "Ranjit Avasarala" To: , Subject: RE: [Sip] query Date: Thu, 14 Mar 2002 09:44:37 -0600 Message-ID: <000a01c1cb6f$264c2f60$9800000a@RANJIT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: High In-Reply-To: <001d01c1cb9b$49696d60$070a0a0a@liastha.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi The best place to start with RFC2543 which gives u a detailed step by step description of SIP Protocol. For free software go to http://www.vovida.org or http://www.sipcentre.com Good Luck... Regards Ranjit -----Original Message----- From: anand [mailto:anand@asthatech.com] Sent: Thursday, March 14, 2002 3:01 PM To: sip@ietf.org Subject: [Sip] query Hi, I am new to sip technology. If I have to setup a sip network on LAN. what are the component that I will need, and where can I get the relevent free sofware if available. Kindly mail back us ASAP. Regards Anand _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 11:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21341 for ; Thu, 14 Mar 2002 11:24:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10931 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 11:24:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08333; Thu, 14 Mar 2002 11:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08302 for ; Thu, 14 Mar 2002 11:02:48 -0500 (EST) Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20653 for ; Thu, 14 Mar 2002 11:02:45 -0500 (EST) Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2EG2ki01561 for ; Thu, 14 Mar 2002 17:02:47 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host chouette.inria.fr [138.96.24.103] claimed to be sophia.inria.fr Message-ID: <3C90C9A6.502344E6@sophia.inria.fr> Date: Thu, 14 Mar 2002 17:02:46 +0100 From: Abdramane Diallo Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: fr-FR,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP Implementation framework Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi all, Can somebody help me to find documents about SIP implementation framework. Thanks -- Abdramane DIALLO Planete Group,INRIA 2004, Route des Lucioles BP 93 06902 Sophia Antipolis CEDEX France Tel:(+33) 4 92 38 75 63 Fax:(+33) 4 92 38 79 78 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 11:25:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21366 for ; Thu, 14 Mar 2002 11:25:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10993 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 11:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07389; Thu, 14 Mar 2002 10:54:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07357 for ; Thu, 14 Mar 2002 10:54:47 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20425 for ; Thu, 14 Mar 2002 10:54:42 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10852; Thu, 14 Mar 2002 10:54:11 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16444; Thu, 14 Mar 2002 10:54:11 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Mar 2002 10:54:11 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57CC98@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'ranjitka@email.masconit.com'" , anand@asthatech.com, sip@ietf.org Subject: RE: [Sip] query Date: Thu, 14 Mar 2002 10:54:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On the contrary, the best place to start now is: http://search.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.pdf bis-09 is approved by the IESG to become an RFC as soon as it gets through the rfc-editor's queue, and is a far superior document for a newbie than RFC2543 is. Brian > -----Original Message----- > From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com] > Sent: Thursday, March 14, 2002 10:45 AM > To: anand@asthatech.com; sip@ietf.org > Subject: RE: [Sip] query > Importance: High > > > Hi > The best place to start with RFC2543 which gives u a > detailed step by > step description of SIP Protocol. > For free software go to http://www.vovida.org or > http://www.sipcentre.com > > Good Luck... > > Regards > Ranjit > > -----Original Message----- > From: anand [mailto:anand@asthatech.com] > Sent: Thursday, March 14, 2002 3:01 PM > To: sip@ietf.org > Subject: [Sip] query > > > Hi, > I am new to sip technology. If I have to setup a sip network on LAN. > what are the component that I will need, and where can I get the > relevent free sofware if available. Kindly mail back us ASAP. > Regards > Anand > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 11:25:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21401 for ; Thu, 14 Mar 2002 11:25:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11024 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 11:25:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08474; Thu, 14 Mar 2002 11:03:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08441 for ; Thu, 14 Mar 2002 11:03:23 -0500 (EST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20677 for ; Thu, 14 Mar 2002 11:03:20 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8F65B6A901; Thu, 14 Mar 2002 18:03:22 +0200 (EET) Message-ID: <3C90CA20.3070100@piuha.net> Date: Thu, 14 Mar 2002 18:04:48 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: "Peterson, Jon" , "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: Re: [Sip] transport=tls References: <70565611B164D511957A001083FCDD5601870168@va02.va.neustar.com> <15504.49268.508649.869482@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > So let me get this straight: an INVITE with > To: sips:... should fail if somewhere along > the path the next hop is protected, but just > not with TLS? Somebody needs to remind why this > is a Good Thing. Yes... I've been meaning to bring this up too. It would have been sufficient to require that the proxies have direct knowledge of integrity, confidentiality, and replay protection through cryptographic means (e.g. IPsec API or use of TLS). Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 11:54:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22432 for ; Thu, 14 Mar 2002 11:54:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13910 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 11:54:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10162; Thu, 14 Mar 2002 11:19:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10131 for ; Thu, 14 Mar 2002 11:19:38 -0500 (EST) Received: from smtp02do.de.uu.net (smtp02do.de.uu.net [192.76.144.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21146 for ; Thu, 14 Mar 2002 11:19:34 -0500 (EST) Received: from penelope.materna.de (penelope.materna.de [193.96.115.65]) by smtp02do.de.uu.net (5.5.5/5.5.5) with ESMTP id RAA26441; Thu, 14 Mar 2002 17:18:58 +0100 (MET) Received: from ganymed (ganymed.materna.de [139.2.34.141]) by penelope.materna.de (Postfix) with ESMTP id AD1206802; Thu, 14 Mar 2002 17:18:54 +0100 (MET) Received: from pdc-gp.materna.de (actually localhost) by ganymed with Internet with ESMTP; Thu, 14 Mar 2002 17:18:56 +0100 Received: by pdc-gp.materna.de with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 17:18:49 +0100 Message-ID: <73B855B4F72FD411A1CF009027B113C40199F737@taxis.materna.de> From: thomas.nagel@materna.de To: mat@cisco.com Cc: sip@ietf.org Subject: AW: [Sip] transport=tls Date: Thu, 14 Mar 2002 17:18:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA10132 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hello Michael > -----Urspr�ngliche Nachricht----- > Von: Michael Thomas [mailto:mat@cisco.com] > Gesendet: Donnerstag, 14. M�rz 2002 16:24 > An: Peterson, Jon > Cc: 'Dean Willis'; Sean Olson; sip@ietf.org > Betreff: RE: [Sip] transport=tls > > ... > > So let me get this straight: an INVITE with > To: sips:... should fail if somewhere along > the path the next hop is protected, but just > not with TLS? Somebody needs to remind why this > is a Good Thing. Sorry to ask: Which other protection schemes can there be? I would say, a security that is only 'best effort' is nearly useless. It only gives you a secure feeling, but is not safe at all. On the other hand, I admit, it would not help at all if the TLS "null"-encapsulation (i.e. unencrypted mode) were also allowed ;) > Mike BR, Thomas Nagel _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 12:06:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22749 for ; Thu, 14 Mar 2002 12:06:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16294 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 12:06:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12622; Thu, 14 Mar 2002 11:36:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12592 for ; Thu, 14 Mar 2002 11:36:54 -0500 (EST) Received: from uni03du.unity.ncsu.edu (uni03du.unity.ncsu.edu [152.1.2.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21796 for ; Thu, 14 Mar 2002 11:36:51 -0500 (EST) Received: (from prsinha@localhost) by uni03du.unity.ncsu.edu (8.8.4/EC02Jan97) id LAA12096; Thu, 14 Mar 2002 11:35:45 -0500 (EST) Date: Thu, 14 Mar 2002 11:35:45 -0500 (EST) From: Prabhas Ranjan Sinha To: "Rosen, Brian" cc: "'ranjitka@email.masconit.com'" , , , Subject: RE: [Sip] query In-Reply-To: <313680C9A886D511A06000204840E1CF57CC98@whq-msgusr-02.pit.comms.marconi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks Brian for giving tips to the newcomers. Unfortunately there are a few on this listserv who doesnt like this idea and end up discouraging people saying that "This is not the place for newcomers".... I hope they are listening to me. It hardly takes a few minutes to clarify their queries. Prabhas On Thu, 14 Mar 2002, Rosen, Brian wrote: > On the contrary, the best place to start now is: > http://search.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.pdf > > bis-09 is approved by the IESG to become an RFC as soon as it gets through > the rfc-editor's queue, and is a far superior document for a > newbie than RFC2543 is. > > Brian > > > -----Original Message----- > > From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com] > > Sent: Thursday, March 14, 2002 10:45 AM > > To: anand@asthatech.com; sip@ietf.org > > Subject: RE: [Sip] query > > Importance: High > > > > > > Hi > > The best place to start with RFC2543 which gives u a > > detailed step by > > step description of SIP Protocol. > > For free software go to http://www.vovida.org or > > http://www.sipcentre.com > > > > Good Luck... > > > > Regards > > Ranjit > > > > -----Original Message----- > > From: anand [mailto:anand@asthatech.com] > > Sent: Thursday, March 14, 2002 3:01 PM > > To: sip@ietf.org > > Subject: [Sip] query > > > > > > Hi, > > I am new to sip technology. If I have to setup a sip network on LAN. > > what are the component that I will need, and where can I get the > > relevent free sofware if available. Kindly mail back us ASAP. > > Regards > > Anand > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Prabhas +++++++++++++ Graduate Research Assistant Dept of Computer Engineering North Carolina State University Raleigh, NC 27695 USA ***************************************** There is no wisdom greater than kindness. ***************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 12:08:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22847 for ; Thu, 14 Mar 2002 12:08:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16555 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 12:08:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13202; Thu, 14 Mar 2002 11:44:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13170 for ; Thu, 14 Mar 2002 11:44:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22034 for ; Thu, 14 Mar 2002 11:44:52 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EGiPd03153 for ; Thu, 14 Mar 2002 08:44:25 -0800 (PST) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACQ51872; Thu, 14 Mar 2002 08:44:24 -0800 (PST) Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Re: REFER security Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I'm a little unclear whether it is REFER that needs security, or its usage. - A REFER which starts a new dialog should be challenged just like any other request that starts a new dialog (INVITE, SUBSCRIBE). - A REFER in the context of an existing dialog should be treated just like any other request in that context (reINVITE, BYE). If you are using TLS, you don't have any reason to challenge these requests, if you aren't using TLS you should probably challenge these requests. I think what we are talking about is the security or introduction of the triggered request. Can we reasonably discuss this issue in each "usage" of REFER, the first being cc-transfer? thanks, -rohan ------------------ To: "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] Status of REFER From: Alan Johnston Date: Tue, 12 Mar 2002 12:43:21 -0600 Importance: Normal In-reply-to: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> List-Id: Session Initiation Protocol Sender: sip-admin@ietf.org -------------------------------------------------------------------------------- Robert, I'm confused about this. We decided a while back to remove a REFER specific security scheme in favor of a more general SIP security approach. Now that we have the general SIP security scheme in bis, you are suggesting that we have to add a REFER specific security scheme back in? This makes no sense. Also, I feel that this is a specific case of the more general problem of how to transport and pass around an "authorization token" for want of a better description in SIP. It could authorize a transfer, a call back through a gateway, a one-time use of a special SIP service, etc, as briefly mentioned in the Multiparty Framework document. I am in favor of solving this general problem, not inventing a REFER specific approach (again) which may or may not work for the more general case. REFER is already way, way, way behind schedule - lets not delay any further by wading into another security quagmire - please. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Robert Sparks > Sent: Tuesday, March 12, 2002 9:06 AM > To: sip@ietf.org > Subject: [Sip] Status of REFER > > > First - many thanks to those people who found the time to > comment on the current REFER draft during the bis-storm. > > The feedback I received indicates that we should alter the > plan discussed in SLC. Specifically, we should not advance > the REFER draft without a concrete mechanism for securing > information passed from the referror through the referree > to the refer target). I'm working on a couple of mechanisms now. > > The draft also needs to be realigned with the new SIP and > SIP-events RFCs. For instance, the ;cseq= parameter should > be replaced with the more general ;id= parameter in events. > > > RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 12:55:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23971 for ; Thu, 14 Mar 2002 12:55:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20031 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 12:55:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18029; Thu, 14 Mar 2002 12:27:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18000 for ; Thu, 14 Mar 2002 12:27:11 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23345 for ; Thu, 14 Mar 2002 12:27:08 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2EHQLf13469; Thu, 14 Mar 2002 12:26:22 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 11:26:16 -0600 Message-ID: <70565611B164D511957A001083FCDD560187016C@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: RE: [Sip] transport=tls Date: Thu, 14 Mar 2002 11:26:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Yes, SIPS is a TLS-specific mechanism. Similarly, HTTPS does not suggest that a particular set of security principles have been upheld to secure the traffic, rather, it is a TLS-specific mechanism. SIPS is a good thing because it normalizes the security expectations of the sender and receiver of a request; for example, it also entails the use of a particular ciphersuite to secure the traffic. Note that the 'path' in this instance refers to a collection of proxies server, entities that MUST support TLS. Once a SIPS request has reached the proxy server responsible for the destination domain, this TLS restriction for forwarding to the next hop is lifted (Dean alluded to this in his note). Presumably, end-users would have registered an appropriate contact address with the domain's location service that reflects their security capabilities and preferences; since UAs are not required to support TLS, this allows security through some other means. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, March 14, 2002 7:24 AM > To: Peterson, Jon > Cc: 'Dean Willis'; Sean Olson; sip@ietf.org > Subject: RE: [Sip] transport=tls > > > Peterson, Jon writes: > > According to bis09, transport=tls has been deprecated. For > the purposes of > > backwards compatibility, the former transport=tls > mechanism would be treated > > roughly the same way as the SIPS URI scheme; the two > important differences > > are that transport=tls assumes TCP, and that a number of > specific rules have > > been mandated for handling the SIPS URI that presumably > wouldn't hold for > > transport=tls. > > > > Either of the meanings that Dean alludes to below can be > expressed by the > > SIPS URI scheme in varying contexts. The use of SIPS in a > Request-URI > > mandates the latter meaning (use TLS for the whole > signaling path), while > > use in contexts such as a Record-Route, a Contact address > of a registration, > > or in a preferred NAPTR record can suggest to the use of > TLS over particular > > segments of a signaling path. > > So let me get this straight: an INVITE with > To: sips:... should fail if somewhere along > the path the next hop is protected, but just > not with TLS? Somebody needs to remind why this > is a Good Thing. > > Mike > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 12:56:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23995 for ; Thu, 14 Mar 2002 12:56:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20100 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 12:56:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17662; Thu, 14 Mar 2002 12:21:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17631 for ; Thu, 14 Mar 2002 12:21:42 -0500 (EST) Received: from f1ee40-20.idc1.level3.com (machine77.Level3.com [209.244.4.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23231 for ; Thu, 14 Mar 2002 12:21:38 -0500 (EST) From: John.Hearty@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-20.idc1.level3.com (8.9.3/8.9.3) with ESMTP id RAA21160; Thu, 14 Mar 2002 17:21:09 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 10:21:08 -0700 Message-ID: <95CCE2787FB8C2498901DCC301017BE2053DC3@idc1exc0003.corp.global.level3.com> To: prsinha@unity.ncsu.edu Cc: ranjitka@email.masconit.com, anand@asthatech.com, sip@ietf.org, Abdramane.Diallo@sophia.inria.fr Subject: RE: [Sip] query Date: Thu, 14 Mar 2002 10:21:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This list is for the development of the SIP protocol. Questions should be directed to the sip-implementors@cs.columbia.edu list, not here. This is not meant to scorn newcomers, just keep the focus of the SIP WG and keep the traffic down, as this is often a very busy list. Sorry no one directed this thread there earlier. -----Original Message----- From: Prabhas Ranjan Sinha [mailto:prsinha@unity.ncsu.edu] Sent: Thursday, March 14, 2002 9:36 AM To: Rosen, Brian Cc: 'ranjitka@email.masconit.com'; anand@asthatech.com; sip@ietf.org; Abdramane.Diallo@sophia.inria.fr Subject: RE: [Sip] query Thanks Brian for giving tips to the newcomers. Unfortunately there are a few on this listserv who doesnt like this idea and end up discouraging people saying that "This is not the place for newcomers".... I hope they are listening to me. It hardly takes a few minutes to clarify their queries. Prabhas On Thu, 14 Mar 2002, Rosen, Brian wrote: > On the contrary, the best place to start now is: > http://search.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.pdf > > bis-09 is approved by the IESG to become an RFC as soon as it gets through > the rfc-editor's queue, and is a far superior document for a > newbie than RFC2543 is. > > Brian > > > -----Original Message----- > > From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com] > > Sent: Thursday, March 14, 2002 10:45 AM > > To: anand@asthatech.com; sip@ietf.org > > Subject: RE: [Sip] query > > Importance: High > > > > > > Hi > > The best place to start with RFC2543 which gives u a > > detailed step by > > step description of SIP Protocol. > > For free software go to http://www.vovida.org or > > http://www.sipcentre.com > > > > Good Luck... > > > > Regards > > Ranjit > > > > -----Original Message----- > > From: anand [mailto:anand@asthatech.com] > > Sent: Thursday, March 14, 2002 3:01 PM > > To: sip@ietf.org > > Subject: [Sip] query > > > > > > Hi, > > I am new to sip technology. If I have to setup a sip network on LAN. > > what are the component that I will need, and where can I get the > > relevent free sofware if available. Kindly mail back us ASAP. > > Regards > > Anand > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Prabhas +++++++++++++ Graduate Research Assistant Dept of Computer Engineering North Carolina State University Raleigh, NC 27695 USA ***************************************** There is no wisdom greater than kindness. ***************************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 13:42:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25213 for ; Thu, 14 Mar 2002 13:42:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23296 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 13:42:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21481; Thu, 14 Mar 2002 13:14:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21452 for ; Thu, 14 Mar 2002 13:14:46 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24535 for ; Thu, 14 Mar 2002 13:14:44 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 89BBD1E055; Thu, 14 Mar 2002 13:14:44 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA20457; Thu, 14 Mar 2002 13:14:41 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA99404; Thu, 14 Mar 2002 13:13:29 -0500 (EST) Date: Thu, 14 Mar 2002 13:13:29 -0500 (EST) Message-Id: <200203141813.NAA99404@fish.research.att.com> To: rohan@cisco.com Cc: sip@ietf.org Subject: [Sip] Re: REFER security Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The issue that I raised with REFER security during its last-call period last year was the inability of the transfer-target to authenticate the Referred-By header with the transferor. While there may be an authenticated relationship between the transferee and the transferor (established by an INVITE, and used by the REFER), and an authenticated relationship between the transferee and the transfer-target (established by the REFER-initiated INVITE), there is no way for the transfer-target (i.e. UAS in the second INVITE) to verify that the transferor really did send a REFER to the UAC. The result is that the only reasonable policy of a UAS on receiving an INVITE containing a Referred-By header is to ignore it. It can only be utilized and believed within a very limited scope that rivals the applicability statement in the privacy draft. If the basic mechanism is of such limited scope, it seems less than useful to discuss security for each separate usage of REFER. In my last-call review of draft-ietf-sip-refer-02, message dated 13 Nov 2001, I proposed one solution. An additional 4xx error response would be sent from transfer-target to transferee, which would contain a challenge. The transferee would send this challenge to the transferer in a NOTIFY, who would respond with an updated REFER with the proper response. This response would then be included in a new INVITE to the transfer-target. Lots of details TBD, like what additional headers are included in the calculation of the response. An example of the problem with the current draft: Consider the simple case of a blind transfer (described in Section 6 of draft-ietf-sip-cc-transfer-05): Person X calls the CEO of a corporation, and the call is intercepted by a screener (S). Screener is the transferor, X is the transferee, and CEO is transfer-target. Screener sends REFER to X, then X sends INVITE to CEO's private address with Referred-By: S. So the next time X wants to call CEO, why go through the screener? X has the magic Referred-By value to go direct. CEO gets unscreened calls, and removes SIP phones from company. Bill Marshall wtm@research.att.com -----original message----- Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Subject: [Sip] Re: REFER security Hi, I'm a little unclear whether it is REFER that needs security, or its usage. - A REFER which starts a new dialog should be challenged just like any other request that starts a new dialog (INVITE, SUBSCRIBE). - A REFER in the context of an existing dialog should be treated just like any other request in that context (reINVITE, BYE). If you are using TLS, you don't have any reason to challenge these requests, if you aren't using TLS you should probably challenge these requests. I think what we are talking about is the security or introduction of the triggered request. Can we reasonably discuss this issue in each "usage" of REFER, the first being cc-transfer? thanks, -rohan ------------------ To: "'Robert Sparks'" , sip@ietf.org Subject: RE: [Sip] Status of REFER From: Alan Johnston Date: Tue, 12 Mar 2002 12:43:21 -0600 Importance: Normal In-reply-to: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> List-Id: Session Initiation Protocol Sender: sip-admin@ietf.org -------------------------------------------------------------------------------- Robert, I'm confused about this. We decided a while back to remove a REFER specific security scheme in favor of a more general SIP security approach. Now that we have the general SIP security scheme in bis, you are suggesting that we have to add a REFER specific security scheme back in? This makes no sense. Also, I feel that this is a specific case of the more general problem of how to transport and pass around an "authorization token" for want of a better description in SIP. It could authorize a transfer, a call back through a gateway, a one-time use of a special SIP service, etc, as briefly mentioned in the Multiparty Framework document. I am in favor of solving this general problem, not inventing a REFER specific approach (again) which may or may not work for the more general case. REFER is already way, way, way behind schedule - lets not delay any further by wading into another security quagmire - please. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Robert Sparks > Sent: Tuesday, March 12, 2002 9:06 AM > To: sip@ietf.org > Subject: [Sip] Status of REFER > > > First - many thanks to those people who found the time to > comment on the current REFER draft during the bis-storm. > > The feedback I received indicates that we should alter the > plan discussed in SLC. Specifically, we should not advance > the REFER draft without a concrete mechanism for securing > information passed from the referror through the referree > to the refer target). I'm working on a couple of mechanisms now. > > The draft also needs to be realigned with the new SIP and > SIP-events RFCs. For instance, the ;cseq= parameter should > be replaced with the more general ;id= parameter in events. > > > RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 14:20:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26876 for ; Thu, 14 Mar 2002 14:20:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27037 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 14:20:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24520; Thu, 14 Mar 2002 13:55:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24490 for ; Thu, 14 Mar 2002 13:55:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25908 for ; Thu, 14 Mar 2002 13:55:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2EItPS23610 for ; Thu, 14 Mar 2002 12:55:25 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2EItPL04778 for ; Thu, 14 Mar 2002 12:55:25 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g2EItOE18247 for ; Thu, 14 Mar 2002 13:55:24 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 13:55:24 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037558@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Thu, 14 Mar 2002 13:55:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Minor Comment on SIP: Locating SIP Servers : SRV-06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Section 4.1: Example on NATPR - The replacement for TCP should read _sip_tcp.School.edu rather than _sip_tcp.example.com to align with the text. Rgds/gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 14:20:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26908 for ; Thu, 14 Mar 2002 14:20:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27061 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 14:20:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25977; Thu, 14 Mar 2002 14:06:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25946 for ; Thu, 14 Mar 2002 14:06:37 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26367 for ; Thu, 14 Mar 2002 14:06:34 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2EJ61h06972; Thu, 14 Mar 2002 11:06:04 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABC89817; Thu, 14 Mar 2002 11:03:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07369; Thu, 14 Mar 2002 11:05:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15504.62613.728089.286787@thomasm-u1.cisco.com> Date: Thu, 14 Mar 2002 11:05:57 -0800 (PST) To: Rohan Mahy Cc: sip@ietf.org Subject: [Sip] Re: REFER security In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy writes: > > Hi, > > I'm a little unclear whether it is REFER that needs security, or its > usage. > > - A REFER which starts a new dialog should be challenged just like any > other request that starts a new dialog (INVITE, SUBSCRIBE). > > - A REFER in the context of an existing dialog should be treated just like > any other request in that context (reINVITE, BYE). If you are using TLS, > you don't have any reason to challenge these requests, if you aren't using > TLS you should probably challenge these requests. Let's be careful here. Authentication != authorization. For example, a UAC can identify myself to my UAS, but that says nothing about whether my screener authorized that UAC to get past it for the REFER/INVITE I see incoming. I don't see the current set of mechanisms as providing the necessary functionality. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 14:21:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26951 for ; Thu, 14 Mar 2002 14:21:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27171 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 14:21:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26110; Thu, 14 Mar 2002 14:07:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26081 for ; Thu, 14 Mar 2002 14:07:28 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26396 for ; Thu, 14 Mar 2002 14:07:25 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2EJ5vI10783 for ; Thu, 14 Mar 2002 14:05:57 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2EJ5vk10770 for ; Thu, 14 Mar 2002 14:05:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Proxies Can Modify SDP? Date: Thu, 14 Mar 2002 12:08:04 -0700 Message-ID: Thread-Topic: [Sip] Proxies Can Modify SDP? Thread-Index: AcGuW8qk/6KRPAbqRi6PwDYQ+Pf/LwdL0RIQ From: "Zmolek, Andrew (Andrew)" To: "Paul Sijben" , "Christer Holmberg" Cc: "Tom-PT Taylor" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA26082 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit We've been avoiding the terminology mess by calling this type of box an ALG (Application Layer Gateway), considering that B2BUA implies full regeneration rather than rewriting and B2BUA's by their nature don't deal with the media streams. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Paul Sijben [mailto:sijben@lucent.com] Sent: Tuesday, February 05, 2002 8:10 AM To: Christer Holmberg Cc: Tom-PT Taylor; 'sip@ietf.org' Subject: Re: [Sip] Proxies Can Modify SDP? The discussion on the TIPHON list was how such a box should be called. TIPHON has been using the term proxy for such a box for a while but it seemed not appropriate usage since a proxy was intended as a routing element ONLY. So we shwitched to B2BUA. However that terms has been scrapped now from the draft. Paul Christer Holmberg wrote: > > Hi, > > A proxy controlling a media firewall, and/or doing some kind of "codec > filtering", should be able to modify the SDP, right? > > Regards, > > Christer Holmberg > Ericsson Finland > > >I've been involved in a little bit of correspondence with TIPHON WG 3, > >where there is some question whether proxies are allowed to modify > >SDP. I know this has shown up in E-mail, but it does not show up in > >2543bis. Could someone confirm this so I can forward the message to > >TIPHON? > > > >Tom Taylor > >taylor@nortelnetworks.com > >Ph. +1 613 736 0961 (ESN 396 1490) > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Paul Sijben Tel:+31 356874774 Bell Labs - Advanced Technologies Fax:+31 356875954 Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben Huizen, The Netherlands _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 14:28:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27234 for ; Thu, 14 Mar 2002 14:28:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27835 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 14:28:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26536; Thu, 14 Mar 2002 14:14:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26504 for ; Thu, 14 Mar 2002 14:14:12 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26563 for ; Thu, 14 Mar 2002 14:14:09 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2EJDZT24905; Thu, 14 Mar 2002 11:13:35 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABC90115; Thu, 14 Mar 2002 11:11:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA07372; Thu, 14 Mar 2002 11:13:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15504.63070.281444.596014@thomasm-u1.cisco.com> Date: Thu, 14 Mar 2002 11:13:34 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: RE: [Sip] transport=tls In-Reply-To: <70565611B164D511957A001083FCDD560187016C@va02.va.neustar.com> References: <70565611B164D511957A001083FCDD560187016C@va02.va.neustar.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > Yes, SIPS is a TLS-specific mechanism. Similarly, HTTPS does not suggest > that a particular set of security principles have been upheld to secure the > traffic, rather, it is a TLS-specific mechanism. SIPS is a good thing > because it normalizes the security expectations of the sender and receiver > of a request; for example, it also entails the use of a particular > ciphersuite to secure the traffic. Um, no it doesn't. All it says is that you must use TLS between each hop. There is nothing that says that if you use AES-256 and SHA2 on your first hop that you're going to get it on each subsequent hop. Indeed, since TLS allows anonymous clients, you're not even assured mutual authentication on each hop. > Note that the 'path' in this instance refers to a collection of proxies > server, entities that MUST support TLS. MUST support != MUST use. Mike _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 15:35:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29865 for ; Thu, 14 Mar 2002 15:35:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05566 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 15:35:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03319; Thu, 14 Mar 2002 15:18:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03291 for ; Thu, 14 Mar 2002 15:18:18 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29182 for ; Thu, 14 Mar 2002 15:18:14 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2EKGhd10633; Thu, 14 Mar 2002 14:16:43 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 14:16:38 -0600 Message-ID: <70565611B164D511957A001083FCDD560187016F@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Thomas'" , "Peterson, Jon" Cc: "'Dean Willis'" , Sean Olson , sip@ietf.org Subject: RE: [Sip] transport=tls Date: Thu, 14 Mar 2002 14:16:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I was just referring to the fact that the specification (bis09 26.2.2) says that you SHOULD use TLS_RSA_WITH_AES_128_CBC_SHA and mutual authentication for SIPS requests. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, March 14, 2002 11:14 AM > To: Peterson, Jon > Cc: 'Michael Thomas'; 'Dean Willis'; Sean Olson; sip@ietf.org > Subject: RE: [Sip] transport=tls > [snip] > ... it also entails the use of a particular ciphersuite to secure the traffic. > > Um, no it doesn't. All it says is that you must > use TLS between each hop. There is nothing that > says that if you use AES-256 and SHA2 on your > first hop that you're going to get it on each > subsequent hop. Indeed, since TLS allows > anonymous clients, you're not even assured > mutual authentication on each hop. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 15:37:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29918 for ; Thu, 14 Mar 2002 15:37:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA05749 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 15:37:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03652; Thu, 14 Mar 2002 15:21:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03614 for ; Thu, 14 Mar 2002 15:21:50 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29340 for ; Thu, 14 Mar 2002 15:21:46 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GSZ00I01CJA1I@firewall.wcom.com> for sip@ietf.org; Thu, 14 Mar 2002 20:21:10 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GSZ00G8MCH1GH@firewall.wcom.com>; Thu, 14 Mar 2002 20:21:09 +0000 (GMT) Received: from dgismtp06.wcomnet.com by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSZ00601CGH3I@dgismtp06.wcomnet.com>; Thu, 14 Mar 2002 20:20:00 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp06.wcomnet.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GSZ003CZCH6RY@dgismtp06.wcomnet.com>; Thu, 14 Mar 2002 20:19:55 +0000 (GMT) Date: Thu, 14 Mar 2002 14:19:57 -0600 From: Henry Sinnreich Subject: RE: [Sip] SIP Implementation framework In-reply-to: <3C90C9A6.502344E6@sophia.inria.fr> To: "'Abdramane Diallo'" , sip@ietf.org Message-id: <000001c1cb95$9c985880$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Can somebody help me to find documents about SIP > implementation framework. A good place to start is: http://search.ietf.org/internet-drafts/draft-ietf-sipping-cc-framework-0 0.txt And http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-component s-01.txt Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Abdramane Diallo > Sent: Thursday, March 14, 2002 10:03 AM > To: sip@ietf.org > Subject: [Sip] SIP Implementation framework > > > Hi all, > Can somebody help me to find documents about SIP > implementation framework. Thanks > -- > Abdramane DIALLO > Planete Group,INRIA > 2004, Route des Lucioles BP 93 > 06902 Sophia Antipolis CEDEX France > Tel:(+33) 4 92 38 75 63 Fax:(+33) 4 92 38 79 78 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Mar 14 16:05:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00803 for ; Thu, 14 Mar 2002 16:05:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07917 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 16:05:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06219; Thu, 14 Mar 2002 15:44:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06186 for ; Thu, 14 Mar 2002 15:44:16 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00131 for ; Thu, 14 Mar 2002 15:44:12 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2EKhjS24836 for ; Thu, 14 Mar 2002 14:43:45 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2EKhic23859 for ; Thu, 14 Mar 2002 14:43:44 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g2EKhiE26688 for ; Thu, 14 Mar 2002 15:43:44 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 15:43:44 -0500 Message-ID: <32CD630F6CBED411AE180008C7894CBC0C03755B@lmc37.lmc.ericsson.se> From: "George Foti (LMC)" To: "'sip@ietf.org'" Date: Thu, 14 Mar 2002 15:43:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question on Locating SIP Servers -06 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Section 4.2 Determining Port and IP. Quoting the last paragraph. "If no SRV records were found, the client performs an A or AAA record lookup of the domain name. The result will be a list of IP addresses each of which can be contaced at the specific port from the URI and transport protocol determined previously." Doesn't that leave the case where transport and ports are unspecified with an undefined tagert port. The target transport will be found through a combination of NAPTR & SRV queries. It is unclear where the port, refered in the text above, will be derived from ? /gf _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 18:52:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05102 for ; Thu, 14 Mar 2002 18:52:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17553 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 18:52:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15901; Thu, 14 Mar 2002 18:17:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15873 for ; Thu, 14 Mar 2002 18:17:38 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04074 for ; Thu, 14 Mar 2002 18:17:35 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8C8E11E04A for ; Thu, 14 Mar 2002 18:17:35 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA27298; Thu, 14 Mar 2002 18:17:32 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id SAA91292; Thu, 14 Mar 2002 18:17:11 -0500 (EST) Date: Thu, 14 Mar 2002 18:17:11 -0500 (EST) Message-Id: <200203142317.SAA91292@fish.research.att.com> To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Subject: [Sip] Last Call comments on manyfolks-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One of the pieces lost in the re-write between manyfolks-03 and -05 is all the spec language about the UAS sending its answer in a 183 (Session Progress) provisional response, and when the UAS needs to include a confirmation request in that answer. When the offer is contained in a 1xx reliable provisional response, the rules already require the answer to be in the PRACK. However, when the offer is in the INVITE, nothing (except for the desire for a working system) is requiring the UAS to send the answer as shown in the examples in section 11. Two cases need to be covered. First, the UAC may need the destination information in order to make its local segmented resource reservation, and to establish the flowspec through firewalls etc. Second, the UAS may need confirmation for any aspect that it can't guarantee itself. I believe that wording the requirement around the second case will also include the first case. I propose the following text be added into section 6, just after the indented motivation paragraph beginning "Note that in this case..." A UAS that is not capable of unilaterally meeting all of the mandatory preconditions MUST include a confirm-status attribute in the SDP (offer or answer) that it sends (see Section 7). Further, an SDP (offer or answer) that contains a confirm-status attribute MUST be sent as soon as allowed by the SIP offer/answer rules. Hopefully the above text also covers the case where the offer is sent by the UAS in 183 without mandatory preconditions, and the answer from the UAC in the PRACK upgrades them to mandatory. The UAS then needs to send a new offer with the confirm-status attribute, presumably in another 183 reliable provisional response. Two other places need spec language. The last paragraph of section 5.1 should contain a MUST: With the transaction status table, the user agent MUST generate the current-status and the desired status lines following the syntax of Section 4 and the rules described below in Section 5.1.1. Also, in section 5.2, in the paragraph after Table 3: Once both tables have been updated, an asnwer MUST be generated following the rules described in Section 5.1.1 and taking into account ..... And, a nit. In section 11.2, SDP1 is generated by A, not B. SDP1: A includes local and remote QoS preconditions in the ..... Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 21:22:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08456 for ; Thu, 14 Mar 2002 21:22:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27802 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 21:22:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25283; Thu, 14 Mar 2002 20:57:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25248 for ; Thu, 14 Mar 2002 20:57:34 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07638 for ; Thu, 14 Mar 2002 20:57:31 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2F1v3h27318; Thu, 14 Mar 2002 17:57:03 -0800 (PST) Received: from dhcp-128-107-142-216.cisco.com (dhcp-128-107-142-216.cisco.com [128.107.142.216]) by imop.cisco.com (Mirapoint) with ESMTP id ACQ60441; Thu, 14 Mar 2002 17:57:01 -0800 (PST) Date: Thu, 14 Mar 2002 17:54:54 -0800 (Pacific Standard Time) From: Rohan Mahy To: William Marshall cc: sip@ietf.org Subject: Re: [Sip] Re: REFER security In-Reply-To: <200203141813.NAA99404@fish.research.att.com> Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On Thu, 14 Mar 2002, William Marshall wrote: > The issue that I raised with REFER security during its last-call period > last year was the inability of the transfer-target to authenticate > the Referred-By header with the transferor. While there may be > an authenticated relationship between the transferee and the transferor > (established by an INVITE, and used by the REFER), and an authenticated > relationship between the transferee and the transfer-target (established by > the REFER-initiated INVITE), there is no way for the transfer-target > (i.e. UAS in the second INVITE) to verify that the transferor really > did send a REFER to the UAC. Then you are discussing the security of cc-transfer, not the security of REFER. This doesn't mean we don't need a solution, but figuring out how to trust a header in an INVITE doesn't exactly seem like a job for the document that defines REFER. thanks, -rohan > The result is that the only reasonable policy of a UAS on receiving > an INVITE containing a Referred-By header is to ignore it. It can > only be utilized and believed within a very limited scope that rivals > the applicability statement in the privacy draft. > > If the basic mechanism is of such limited scope, it seems less than > useful to discuss security for each separate usage of REFER. > > In my last-call review of draft-ietf-sip-refer-02, message dated 13 Nov 2001, > I proposed one solution. An additional 4xx error response would be > sent from transfer-target to transferee, which would contain a challenge. > The transferee would send this challenge to the transferer in a NOTIFY, > who would respond with an updated REFER with the proper response. This > response would then be included in a new INVITE to the transfer-target. > Lots of details TBD, like what additional headers are included in the > calculation of the response. > > An example of the problem with the current draft: > Consider the simple case of a blind transfer (described in Section 6 > of draft-ietf-sip-cc-transfer-05): > Person X calls the CEO of a corporation, and the call is intercepted by > a screener (S). Screener is the transferor, X is the transferee, and > CEO is transfer-target. Screener sends REFER to X, then X sends INVITE > to CEO's private address with Referred-By: S. So the next time X wants > to call CEO, why go through the screener? X has the magic Referred-By > value to go direct. CEO gets unscreened calls, and removes SIP phones > from company. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time) > From: Rohan Mahy > To: sip@ietf.org > Subject: [Sip] Re: REFER security > > > Hi, > > I'm a little unclear whether it is REFER that needs security, or its > usage. > > - A REFER which starts a new dialog should be challenged just like any > other request that starts a new dialog (INVITE, SUBSCRIBE). > > - A REFER in the context of an existing dialog should be treated just like > any other request in that context (reINVITE, BYE). If you are using TLS, > you don't have any reason to challenge these requests, if you aren't using > TLS you should probably challenge these requests. > > I think what we are talking about is the security or introduction of the > triggered request. Can we reasonably discuss this issue in each > "usage" of REFER, the first being cc-transfer? > > thanks, > -rohan > > > > ------------------ > To: "'Robert Sparks'" , sip@ietf.org > Subject: RE: [Sip] Status of REFER > From: Alan Johnston > Date: Tue, 12 Mar 2002 12:43:21 -0600 > Importance: Normal > In-reply-to: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> > List-Id: Session Initiation Protocol > Sender: sip-admin@ietf.org > > -------------------------------------------------------------------------------- > > Robert, > > I'm confused about this. We decided a while back to remove a REFER > specific security scheme in favor of a more general SIP security > approach. > > Now that we have the general SIP security scheme in bis, you are > suggesting that we have to add a REFER specific security scheme back in? > This makes no sense. > > Also, I feel that this is a specific case of the more general problem of > how to transport and pass around an "authorization token" for want of a > better description in SIP. It could authorize a transfer, a call back > through a gateway, a one-time use of a special SIP service, etc, as > briefly mentioned in the Multiparty Framework document. > > I am in favor of solving this general problem, not inventing a REFER > specific approach (again) which may or may not work for the more general > case. > > REFER is already way, way, way behind schedule - lets not delay any > further by wading into another security quagmire - please. > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.com > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Robert Sparks > > Sent: Tuesday, March 12, 2002 9:06 AM > > To: sip@ietf.org > > Subject: [Sip] Status of REFER > > > > > > First - many thanks to those people who found the time to > > comment on the current REFER draft during the bis-storm. > > > > The feedback I received indicates that we should alter the > > plan discussed in SLC. Specifically, we should not advance > > the REFER draft without a concrete mechanism for securing > > information passed from the referror through the referree > > to the refer target). I'm working on a couple of mechanisms now. > > > > The draft also needs to be realigned with the new SIP and > > SIP-events RFCs. For instance, the ;cseq= parameter should > > be replaced with the more general ;id= parameter in events. > > > > > > RjS > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 21:25:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08536 for ; Thu, 14 Mar 2002 21:25:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA27901 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 21:25:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27254; Thu, 14 Mar 2002 21:11:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27195 for ; Thu, 14 Mar 2002 21:11:18 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08223 for ; Thu, 14 Mar 2002 21:11:14 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2F2Akd07798; Thu, 14 Mar 2002 18:10:46 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABD01274; Thu, 14 Mar 2002 18:08:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA07393; Thu, 14 Mar 2002 18:10:46 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15505.22565.984553.793703@thomasm-u1.cisco.com> Date: Thu, 14 Mar 2002 18:10:45 -0800 (PST) To: Rohan Mahy Cc: William Marshall , sip@ietf.org Subject: Re: [Sip] Re: REFER security In-Reply-To: References: <200203141813.NAA99404@fish.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ?? I thought that cc-transfer was on an informational track? Mike Rohan Mahy writes: > > On Thu, 14 Mar 2002, William Marshall wrote: > > The issue that I raised with REFER security during its last-call period > > last year was the inability of the transfer-target to authenticate > > the Referred-By header with the transferor. While there may be > > an authenticated relationship between the transferee and the transferor > > (established by an INVITE, and used by the REFER), and an authenticated > > relationship between the transferee and the transfer-target (established by > > the REFER-initiated INVITE), there is no way for the transfer-target > > (i.e. UAS in the second INVITE) to verify that the transferor really > > did send a REFER to the UAC. > > Then you are discussing the security of cc-transfer, not the security of > REFER. This doesn't mean we don't need a solution, but figuring out how > to trust a header in an INVITE doesn't exactly seem like a job for the > document that defines REFER. > > thanks, > -rohan > > > The result is that the only reasonable policy of a UAS on receiving > > an INVITE containing a Referred-By header is to ignore it. It can > > only be utilized and believed within a very limited scope that rivals > > the applicability statement in the privacy draft. > > > > If the basic mechanism is of such limited scope, it seems less than > > useful to discuss security for each separate usage of REFER. > > > > In my last-call review of draft-ietf-sip-refer-02, message dated 13 Nov 2001, > > I proposed one solution. An additional 4xx error response would be > > sent from transfer-target to transferee, which would contain a challenge. > > The transferee would send this challenge to the transferer in a NOTIFY, > > who would respond with an updated REFER with the proper response. This > > response would then be included in a new INVITE to the transfer-target. > > Lots of details TBD, like what additional headers are included in the > > calculation of the response. > > > > An example of the problem with the current draft: > > Consider the simple case of a blind transfer (described in Section 6 > > of draft-ietf-sip-cc-transfer-05): > > Person X calls the CEO of a corporation, and the call is intercepted by > > a screener (S). Screener is the transferor, X is the transferee, and > > CEO is transfer-target. Screener sends REFER to X, then X sends INVITE > > to CEO's private address with Referred-By: S. So the next time X wants > > to call CEO, why go through the screener? X has the magic Referred-By > > value to go direct. CEO gets unscreened calls, and removes SIP phones > > from company. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > Date: Thu, 14 Mar 2002 08:42:18 -0800 (Pacific Standard Time) > > From: Rohan Mahy > > To: sip@ietf.org > > Subject: [Sip] Re: REFER security > > > > > > Hi, > > > > I'm a little unclear whether it is REFER that needs security, or its > > usage. > > > > - A REFER which starts a new dialog should be challenged just like any > > other request that starts a new dialog (INVITE, SUBSCRIBE). > > > > - A REFER in the context of an existing dialog should be treated just like > > any other request in that context (reINVITE, BYE). If you are using TLS, > > you don't have any reason to challenge these requests, if you aren't using > > TLS you should probably challenge these requests. > > > > I think what we are talking about is the security or introduction of the > > triggered request. Can we reasonably discuss this issue in each > > "usage" of REFER, the first being cc-transfer? > > > > thanks, > > -rohan > > > > > > > > ------------------ > > To: "'Robert Sparks'" , sip@ietf.org > > Subject: RE: [Sip] Status of REFER > > From: Alan Johnston > > Date: Tue, 12 Mar 2002 12:43:21 -0600 > > Importance: Normal > > In-reply-to: <1015945586.1187.34.camel@dhcp240.dfw.dynamicsoft.com> > > List-Id: Session Initiation Protocol > > Sender: sip-admin@ietf.org > > > > -------------------------------------------------------------------------------- > > > > Robert, > > > > I'm confused about this. We decided a while back to remove a REFER > > specific security scheme in favor of a more general SIP security > > approach. > > > > Now that we have the general SIP security scheme in bis, you are > > suggesting that we have to add a REFER specific security scheme back in? > > This makes no sense. > > > > Also, I feel that this is a specific case of the more general problem of > > how to transport and pass around an "authorization token" for want of a > > better description in SIP. It could authorize a transfer, a call back > > through a gateway, a one-time use of a special SIP service, etc, as > > briefly mentioned in the Multiparty Framework document. > > > > I am in favor of solving this general problem, not inventing a REFER > > specific approach (again) which may or may not work for the more general > > case. > > > > REFER is already way, way, way behind schedule - lets not delay any > > further by wading into another security quagmire - please. > > > > Thanks, > > Alan Johnston > > WorldCom > > sip:alan@siptest.wcom.com > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > > Behalf Of Robert Sparks > > > Sent: Tuesday, March 12, 2002 9:06 AM > > > To: sip@ietf.org > > > Subject: [Sip] Status of REFER > > > > > > > > > First - many thanks to those people who found the time to > > > comment on the current REFER draft during the bis-storm. > > > > > > The feedback I received indicates that we should alter the > > > plan discussed in SLC. Specifically, we should not advance > > > the REFER draft without a concrete mechanism for securing > > > information passed from the referror through the referree > > > to the refer target). I'm working on a couple of mechanisms now. > > > > > > The draft also needs to be realigned with the new SIP and > > > SIP-events RFCs. For instance, the ;cseq= parameter should > > > be replaced with the more general ;id= parameter in events. > > > > > > > > > RjS > > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 14 22:26:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10306 for ; Thu, 14 Mar 2002 22:26:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01738 for sip-archive@odin.ietf.org; Thu, 14 Mar 2002 22:26:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00531; Thu, 14 Mar 2002 22:01:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA00486 for ; Thu, 14 Mar 2002 22:01:07 -0500 (EST) Received: from services.dasecurenetworks.com (adsl-64-219-170-213.dsl.rcsntx.swbell.net [64.219.170.213]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09820 for ; Thu, 14 Mar 2002 22:00:56 -0500 (EST) Received: from dasecurenetworks.com (main1.dasecurenetworks.com [192.168.0.151] (may be forged)) by services.dasecurenetworks.com (8.11.6/8.9.3) with ESMTP id g2F2GOt02171; Thu, 14 Mar 2002 20:16:39 -0600 Message-ID: <3C916477.6B43458E@dasecurenetworks.com> Date: Thu, 14 Mar 2002 21:03:19 -0600 From: Chris Martin Reply-To: cmartin@dasecurenetworks.com X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10enterprise i686) X-Accept-Language: en MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: Paul Sijben , Christer Holmberg , Tom-PT Taylor , sip@ietf.org Subject: Re: [Sip] Proxies Can Modify SDP? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a way wouldnt it be both a B2BUA (for the SIP) as well as an ALG (ALG for the media)? "Zmolek, Andrew (Andrew)" wrote: > > We've been avoiding the terminology mess by calling this type of box an ALG (Application Layer Gateway), considering that B2BUA implies full regeneration rather than rewriting and B2BUA's by their nature don't deal with the media streams. > > --Andy Zmolek > Technology & Standards Engineer > CTO Standards > Avaya Inc. > > zmolek@avaya.com > +1 720 444 4001 > > -----Original Message----- > From: Paul Sijben [mailto:sijben@lucent.com] > Sent: Tuesday, February 05, 2002 8:10 AM > To: Christer Holmberg > Cc: Tom-PT Taylor; 'sip@ietf.org' > Subject: Re: [Sip] Proxies Can Modify SDP? > > The discussion on the TIPHON list was how such a box should be called. > TIPHON has been using the term proxy for such a box for a while but it > seemed not appropriate usage since a proxy was intended as a routing > element ONLY. > > So we shwitched to B2BUA. However that terms has been scrapped now from > the draft. > > Paul > > Christer Holmberg wrote: > > > > Hi, > > > > A proxy controlling a media firewall, and/or doing some kind of "codec > > filtering", should be able to modify the SDP, right? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > >I've been involved in a little bit of correspondence with TIPHON WG 3, > > >where there is some question whether proxies are allowed to modify > > >SDP. I know this has shown up in E-mail, but it does not show up in > > >2543bis. Could someone confirm this so I can forward the message to > > >TIPHON? > > > > > >Tom Taylor > > >taylor@nortelnetworks.com > > >Ph. +1 613 736 0961 (ESN 396 1490) > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Paul Sijben Tel:+31 356874774 > Bell Labs - Advanced Technologies Fax:+31 356875954 > Lucent Technologies (internal) http://voip.nl.lucent.com/~sijben > Huizen, The Netherlands > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 00:46:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13682 for ; Fri, 15 Mar 2002 00:46:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08757 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 00:46:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07548; Fri, 15 Mar 2002 00:14:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07523 for ; Fri, 15 Mar 2002 00:14:22 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13317 for ; Fri, 15 Mar 2002 00:14:21 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2F5Dk318676; Thu, 14 Mar 2002 21:13:46 -0800 (PST) Received: from fluffyw2k (dhcp-128-107-209-62.cisco.com [128.107.209.62]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACI12224; Thu, 14 Mar 2002 21:14:03 -0800 (PST) From: "Cullen Jennings" To: , Subject: RE: [Sip] SIP-H.323 Interworking Date: Thu, 14 Mar 2002 21:13:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Try the list at sip-h323@yahoogroups.com for discussions on this. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > gary.m.sacra@verizon.com > Sent: Wednesday, March 13, 2002 1:54 PM > To: sip@ietf.org > Subject: [Sip] SIP-H.323 Interworking > > > Could someone provide me with the name(s) of the industry > group(s) that are > actively working on the development of a SIP-H.323 interworking function > and the status of that effort? > > Thanks very much in advance, > > Gary Sacra > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 03:52:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23699 for ; Fri, 15 Mar 2002 03:52:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28341 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 03:52:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27935; Fri, 15 Mar 2002 03:39:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27906 for ; Fri, 15 Mar 2002 03:39:27 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23576 for ; Fri, 15 Mar 2002 03:39:23 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA22609; Fri, 15 Mar 2002 09:38:34 +0100 (MET) To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Date: Fri, 15 Mar 2002 09:38:32 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 09:38:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] Manyfolks: the segmented approach Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, The segmented approach defines two tags: local and remote. Are they both really needed ? I have the feeling that a single value should be enough, let's say "local". For the desired-status, you only need to say "I'm using the segmented model", that is, I will not send you e2e resource reservation messages, and therefore each of us has to solve the reservation question independently in its own access network. For the current-status, using a single value means: when I send a current-status, I'm telling you about what *I did* in *my* access network for resource reservation. When I receive a current-status, I'm learning what *you did* in *your* access network for resource reservation. By the way, the example in section 9 seems to me a little bit strange. I agree that you can have several preconditions on the same media stream (even if for complexity reasons, I guess that most people will use only one precondition), but can you still use at the same time the e2e approach *and* the segmented approach for the same media? Can you please explain me how this can work ? Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 03:52:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23722 for ; Fri, 15 Mar 2002 03:52:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA28434 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 03:52:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26553; Fri, 15 Mar 2002 03:18:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26518 for ; Fri, 15 Mar 2002 03:18:34 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23366 for ; Fri, 15 Mar 2002 03:18:27 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA17301; Fri, 15 Mar 2002 09:17:52 +0100 (MET) To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Date: Fri, 15 Mar 2002 09:17:50 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 09:17:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] Manyfolks: e2e meaning Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, In manyfolks-05, it is said that "status type: ...: The end-to-end status reflects the status of the end-to-end resource reservation" In fact, end-to-end means that both end-users will exchange end-to-end some messages using some protocol in order to reserve resources (this could be added for clarification, as it is never said in the draft). My question: Does "end-to-end" mean here RSVP ? If the answer is yes, this is not a very future safe approach for the SDP extensions, as other protocols could be defined also. If the answer is no, how can I know which protocol will be used for end-to-end resource reservation ? Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 04:47:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24698 for ; Fri, 15 Mar 2002 04:47:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA03659 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 04:48:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01280; Fri, 15 Mar 2002 04:26:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01244 for ; Fri, 15 Mar 2002 04:26:46 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24287 for ; Fri, 15 Mar 2002 04:26:42 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 10:37:31 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Sip] SDP in unreliable 18x Reply-to: salreyca@teleco.upv.es Message-ID: <3C91CEEB.30745.1B4138@localhost> Priority: normal In-reply-to: <3C882984.969AFDB2@dynamicsoft.com> X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, please see inline at end, On 7 Mar 2002, at 22:01, Jonathan Rosenberg wrote: > > > Christer Holmberg wrote: > > > > Hi Bob, > > > > > >Now, does this mean I'm not allowed to send an SDP in an UN-reliable > > > >18x? And, if I do, is it then not regardes as an answer? > > > > > > You are allowed to send SDP in an unreliable 1xx. However, it MUST be > > the > > > same as the SDP you will send in a 2xx. The key sentence is "That same > > exact > > > answer MAY also be placed in any provisional responses sent prior to > > the > > > answer." > > > > True. But, in this case the UAC is not allowed to send a new offer (eg > > using > > UPDATE) before it has received the final response. > > Right. The idea was to try and add a semblance of compatibility with > existing implementations. We want everything to be mapped to a set of > non-overlapping O/A exchanges. So, the idea is that the SDP in an > unrealiable 18x, and the SDP in a 2xx, are just the same answer. THus, > we maintain the property of everything being a series of O/A exchanges, > but allow a single answer to be present in multiple sip responses. > > However, it is NOT allowed, to send an offer in INVITE, an answer in a > reliable 183, and then repeat the answer in the next reliable 183. Thats > because the answer has to be in the first reliable response sent back, > which is the first 183. The SDP in the second 183 would be illegal, > since it would be an offer, and those can't go in responses after the > first SDP. I don't quite understand why these new offer on th e reliable 183 would be illegal. Isn't it conveyed on a reliable delivered message. I thought that was the only condition for O/A exchanges. or is it that it's only allowed one O/A exchange per transaction? Thanks Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 04:57:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24910 for ; Fri, 15 Mar 2002 04:57:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04449 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 04:57:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03130; Fri, 15 Mar 2002 04:43:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03097 for ; Fri, 15 Mar 2002 04:43:34 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24601 for ; Fri, 15 Mar 2002 04:43:30 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 10:54:52 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <3C91D2FC.24286.2B265A@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] question on many-folks-draft05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hello, There is no example shown in the draft where the callee, receiving the first INVITE, sends an UPDATE to the caller. Is there any reason for this, isn't it allowed? For what I've read, the UPDATE are treated in the same fashion as the request that created the dialog (section 6.2 draft-ietf-sip- update-00 ), in this case an INVITE, and we all know that the callee can send a re-INVITE to modify session parameters. Is it really bound to the request that created the dialog, or should it be bound to the last request received, and not terminated yet? thanks, Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 05:02:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25015 for ; Fri, 15 Mar 2002 05:02:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA05320 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 05:02:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03844; Fri, 15 Mar 2002 04:50:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03813 for ; Fri, 15 Mar 2002 04:50:27 -0500 (EST) Received: from sophia.inria.fr (sophia.inria.fr [138.96.32.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24777 for ; Fri, 15 Mar 2002 04:50:23 -0500 (EST) Received: from sophia.inria.fr by sophia.inria.fr (8.11.6/8.11.6) with ESMTP id g2F9oOj18994 for ; Fri, 15 Mar 2002 10:50:25 +0100 (MET) X-Authentication-Warning: sophia.inria.fr: Host django.inria.fr [138.96.88.73] claimed to be sophia.inria.fr Message-ID: <3C91C3E0.BF8AA9A@sophia.inria.fr> Date: Fri, 15 Mar 2002 10:50:24 +0100 From: Qiang Ni Organization: INRIA Sophia Antipolis X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: fr, fr-FR, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] test Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It's only a test. Ni -- *********************************** Planete Group, Sophia Antipolis,INRIA,France Qiang.Ni@sophia.inria.fr (+33) 4 92 38 79 59 *********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 06:07:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26226 for ; Fri, 15 Mar 2002 06:07:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA11116 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 06:07:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09936; Fri, 15 Mar 2002 05:54:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09873 for ; Fri, 15 Mar 2002 05:54:17 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26025 for ; Fri, 15 Mar 2002 05:54:13 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FArjV12085 for ; Fri, 15 Mar 2002 05:53:45 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 10:53:44 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB004992396@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Date: Fri, 15 Mar 2002 10:53:43 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Agree! I think the e2e is really useless here. The impression I got from the manyfolks draft is that the only way you can get end to end is using RSVP, because getting a RSVP RESV message is the detection point that end to end is achieved. What happen that one terminal uses RSVP and another terminal uses a protocol called "banana" to do end to end? for sure, this will not work in manyfolks. Therefore, the e2e here simply mandates that it works only if both terminals using the same QoS reservation protocol. So my suggestion is to change the "e2e" parameter to "rsvp", then all the SIP terminal will have to implement RSVP and we all get end to end QoS. By the way, manyfolks says: "B receives RESV messages conforming the reservation." This is WRONG. Any router will route RESV packets even it is not rsvp aware, don't be cheated when getting the RESV message! Therefore, the "e2e" just gives the terminal a chance to be cheated, a terminal can never be sure whether the end to end QoS achieved unless you are in charge of the RSVP admission control for all the routers in the path between UAC and UAS, in other words, all the routers on the path are in your local network, in another words "e2e" = "local". So, please not to introduce any status type in manyfolks, they just can not achieve what they want to achieve. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: 15 March 2002 8:18 To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Subject: [Sip] Manyfolks: e2e meaning Hello, In manyfolks-05, it is said that "status type: ...: The end-to-end status reflects the status of the end-to-end resource reservation" In fact, end-to-end means that both end-users will exchange end-to-end some messages using some protocol in order to reserve resources (this could be added for clarification, as it is never said in the draft). My question: Does "end-to-end" mean here RSVP ? If the answer is yes, this is not a very future safe approach for the SDP extensions, as other protocols could be defined also. If the answer is no, how can I know which protocol will be used for end-to-end resource reservation ? Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 06:38:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26659 for ; Fri, 15 Mar 2002 06:38:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA13014 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 06:38:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11550; Fri, 15 Mar 2002 06:18:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11519 for ; Fri, 15 Mar 2002 06:18:31 -0500 (EST) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26334 for ; Fri, 15 Mar 2002 06:18:27 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g2FBGvk07269; Fri, 15 Mar 2002 22:16:57 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id WAA14856; Fri, 15 Mar 2002 22:18:25 +1100 (EST) Received: from localhost.localdomain (ORSON [146.11.245.172]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GM05N28V; Fri, 15 Mar 2002 22:18:22 +1100 Subject: RE: [Sip] Manyfolks: e2e meaning From: Brian Williams To: "Chen, Xin (Xin)" Cc: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com, sip@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB004992396@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB004992396@en0033exch001u.uk.lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 22:11:12 +1100 Message-Id: <1016190675.2377.10.camel@mindy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi. On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > Agree! I think the e2e is really useless here. The impression I got from the > manyfolks draft is that the only way you can get end to end is using RSVP, > because getting a RSVP RESV message is the detection point that end to end > is achieved. What happen that one terminal uses RSVP and another terminal > uses a protocol called "banana" to do end to end? for sure, this will not > work in manyfolks. Therefore, the e2e here simply mandates that it works > only if both terminals using the same QoS reservation protocol. > So my suggestion is to change the "e2e" parameter to "rsvp", then all the > SIP terminal will have to implement RSVP and we all get end to end QoS. I would not agree with chaging e2e to be RSVP. This would mean the manyfolks draft needs to be updated every time a new protocol is created. Manyfolks should not depend on the actual protocol in use. It would work if A uses RSVP and B uses "banana", as long as there is some point within the network where RSVP interworks with "banana". If there is no interworking, then of course the qos preconditions will not be met because there will be no reply to the RSVP (or the "banana"). /brian > > By the way, manyfolks says: > > "B receives RESV messages conforming the reservation." > > This is WRONG. Any router will route RESV packets even it is not rsvp aware, > don't be cheated when getting the RESV message! Therefore, the "e2e" just > gives the terminal a chance to be cheated, a terminal can never be sure > whether the end to end QoS achieved unless you are in charge of the RSVP > admission control for all the routers in the path between UAC and UAS, in > other words, all the routers on the path are in your local network, in > another words "e2e" = "local". So, please not to introduce any status type > in manyfolks, they just can not achieve what they want to achieve. > > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: 15 March 2002 8:18 > To: Gonzalo.Camarillo@ericsson.com > Cc: sip@ietf.org > Subject: [Sip] Manyfolks: e2e meaning > > > Hello, > > In manyfolks-05, it is said that "status type: ...: The end-to-end status > reflects the status of the end-to-end resource reservation" > In fact, end-to-end means that both end-users will exchange end-to-end some > messages using some protocol in order to reserve resources (this could be > added for clarification, as it is never said in the draft). > > My question: Does "end-to-end" mean here RSVP ? > If the answer is yes, this is not a very future safe approach for the SDP > extensions, as other protocols could be defined also. > If the answer is no, how can I know which protocol will be used for > end-to-end resource reservation ? > > Best regards > Juan Carlos > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 07:16:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27156 for ; Fri, 15 Mar 2002 07:16:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15352 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 07:16:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13395; Fri, 15 Mar 2002 06:45:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA13294 for ; Fri, 15 Mar 2002 06:45:32 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26743 for ; Fri, 15 Mar 2002 06:45:30 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FBjUE22182 for ; Fri, 15 Mar 2002 06:45:30 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 11:45:29 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0049923B1@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Brian Williams , "Chen, Xin (Xin)" Cc: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Date: Fri, 15 Mar 2002 11:45:26 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Brian, See inline please, Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Brian Williams [mailto:brian.williams@ericsson.com.au] Sent: 15 March 2002 11:11 To: Chen, Xin (Xin) Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Hi. On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > Agree! I think the e2e is really useless here. The impression I got from the > manyfolks draft is that the only way you can get end to end is using RSVP, > because getting a RSVP RESV message is the detection point that end to end > is achieved. What happen that one terminal uses RSVP and another terminal > uses a protocol called "banana" to do end to end? for sure, this will not > work in manyfolks. Therefore, the e2e here simply mandates that it works > only if both terminals using the same QoS reservation protocol. > So my suggestion is to change the "e2e" parameter to "rsvp", then all the > SIP terminal will have to implement RSVP and we all get end to end QoS. I would not agree with chaging e2e to be RSVP. This would mean the manyfolks draft needs to be updated every time a new protocol is created. Manyfolks should not depend on the actual protocol in use. [XC]I would never agree either, but I see no difference to use "e2e" or "rsvp" here. It would work if A uses RSVP and B uses "banana", as long as there is some point within the network where RSVP interworks with "banana". If there is no interworking, then of course the qos preconditions will not be met because there will be no reply to the RSVP (or the "banana"). [XC]Ok, Manyfolks will not depend on actually protcols, but depends on interworking between different protocols! That is even worse, if we have 100 different QoS reservation protocols, then we have to have 100 interworking points in my network in order to get my SIP terminal work under manyfolks. Simple question, before you start to devolopement the interwork point, how do you know which protocol you are going to interwork with? Today is Banana, tomorrow maybe something else. So, let's give up the "e2e" idea today to save the cost to develop the interworking point in the future. /brian > > By the way, manyfolks says: > > "B receives RESV messages conforming the reservation." > > This is WRONG. Any router will route RESV packets even it is not rsvp aware, > don't be cheated when getting the RESV message! Therefore, the "e2e" just > gives the terminal a chance to be cheated, a terminal can never be sure > whether the end to end QoS achieved unless you are in charge of the RSVP > admission control for all the routers in the path between UAC and UAS, in > other words, all the routers on the path are in your local network, in > another words "e2e" = "local". So, please not to introduce any status type > in manyfolks, they just can not achieve what they want to achieve. > > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: 15 March 2002 8:18 > To: Gonzalo.Camarillo@ericsson.com > Cc: sip@ietf.org > Subject: [Sip] Manyfolks: e2e meaning > > > Hello, > > In manyfolks-05, it is said that "status type: ...: The end-to-end status > reflects the status of the end-to-end resource reservation" > In fact, end-to-end means that both end-users will exchange end-to-end some > messages using some protocol in order to reserve resources (this could be > added for clarification, as it is never said in the draft). > > My question: Does "end-to-end" mean here RSVP ? > If the answer is yes, this is not a very future safe approach for the SDP > extensions, as other protocols could be defined also. > If the answer is no, how can I know which protocol will be used for > end-to-end resource reservation ? > > Best regards > Juan Carlos > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 07:39:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27492 for ; Fri, 15 Mar 2002 07:39:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA16814 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 07:39:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15509; Fri, 15 Mar 2002 07:20:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15481 for ; Fri, 15 Mar 2002 07:19:56 -0500 (EST) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27194 for ; Fri, 15 Mar 2002 07:19:52 -0500 (EST) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g2FCINk12107; Fri, 15 Mar 2002 23:18:23 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id XAA29193; Fri, 15 Mar 2002 23:19:51 +1100 (EST) Received: from localhost.localdomain (ORSON [146.11.245.172]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GM05NJJ1; Fri, 15 Mar 2002 23:19:48 +1100 Subject: RE: [Sip] Manyfolks: e2e meaning From: Brian Williams To: "Chen, Xin (Xin)" Cc: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com, sip@ietf.org In-Reply-To: <475FF955A05DD411980D00508B6D5FB0049923B1@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0049923B1@en0033exch001u.uk.lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Mar 2002 23:12:37 +1100 Message-Id: <1016194359.2377.19.camel@mindy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit More comments inline. On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > Hi Brian, > > See inline please, > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 11:11 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > > Hi. > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > Agree! I think the e2e is really useless here. The impression I got from > the > > manyfolks draft is that the only way you can get end to end is using RSVP, > > because getting a RSVP RESV message is the detection point that end to end > > is achieved. What happen that one terminal uses RSVP and another terminal > > uses a protocol called "banana" to do end to end? for sure, this will not > > work in manyfolks. Therefore, the e2e here simply mandates that it works > > only if both terminals using the same QoS reservation protocol. > > So my suggestion is to change the "e2e" parameter to "rsvp", then all the > > SIP terminal will have to implement RSVP and we all get end to end QoS. > I would not agree with chaging e2e to be RSVP. This would mean the > manyfolks draft needs to be updated every time a new protocol is > created. Manyfolks should not depend on the actual protocol in use. > > [XC]I would never agree either, but I see no difference to use "e2e" or > "rsvp" here. > > It would work if A uses RSVP and B uses "banana", as long as there is > some point within the network where RSVP interworks with "banana". If > there is no interworking, then of course the qos preconditions will not > be met because there will be no reply to the RSVP (or the "banana"). > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > interworking between different protocols! That is even worse, if we have 100 > different QoS reservation protocols, then we have to have 100 interworking > points in my network in order to get my SIP terminal work under manyfolks. > Simple question, before you start to devolopement the interwork point, how > do you know which protocol you are going to interwork with? Today is Banana, > tomorrow maybe something else. So, let's give up the "e2e" idea today to > save the cost to develop the interworking point in the future. At present we have one e2e protocol (at least if you are considering IP only, it is always possible that terminals may be using other mechanisms such as ATM too, which can be e2e depending on the network). As additional protocols are added, there becomes a need to negotiate the e2e protocol between terminals, and this can include negotiating using capabilities provided by network equipment. Such negotiation would be performed using a protocol aimed for this negotiation. This concept of multiple building blocks which can be used together is a key strategy for extending capabilities in IP networks, and I see no reason not to apply it here too. > > /brian > > > > > By the way, manyfolks says: > > > > "B receives RESV messages conforming the reservation." > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > aware, > > don't be cheated when getting the RESV message! Therefore, the "e2e" just > > gives the terminal a chance to be cheated, a terminal can never be sure > > whether the end to end QoS achieved unless you are in charge of the RSVP > > admission control for all the routers in the path between UAC and UAS, in > > other words, all the routers on the path are in your local network, in > > another words "e2e" = "local". So, please not to introduce any status type > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > > Sent: 15 March 2002 8:18 > > To: Gonzalo.Camarillo@ericsson.com > > Cc: sip@ietf.org > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > Hello, > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end status > > reflects the status of the end-to-end resource reservation" > > In fact, end-to-end means that both end-users will exchange end-to-end > some > > messages using some protocol in order to reserve resources (this could be > > added for clarification, as it is never said in the draft). > > > > My question: Does "end-to-end" mean here RSVP ? > > If the answer is yes, this is not a very future safe approach for the SDP > > extensions, as other protocols could be defined also. > > If the answer is no, how can I know which protocol will be used for > > end-to-end resource reservation ? > > > > Best regards > > Juan Carlos > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 08:22:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28034 for ; Fri, 15 Mar 2002 08:22:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20295 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 08:22:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18281; Fri, 15 Mar 2002 08:05:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18252 for ; Fri, 15 Mar 2002 08:05:52 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27783 for ; Fri, 15 Mar 2002 08:05:48 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 14:17:08 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <3C920264.4321.E4522E@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Subject: [Sip] mayfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, is it allowed to send an answer with preconditions to an offer that didn't contain them (not even the none option tag)? thanks Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 08:23:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28129 for ; Fri, 15 Mar 2002 08:23:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20403 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 08:23:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18658; Fri, 15 Mar 2002 08:09:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07179 for ; Fri, 15 Mar 2002 05:25:52 -0500 (EST) Received: from gatekeeper2.mahindrabt.com (gatekeeper2.mahindrabt.com [203.197.15.67] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25468 for ; Fri, 15 Mar 2002 05:25:46 -0500 (EST) Received: from mahindrabt.com (mailscan.mahindrabt.com [10.2.0.50]) by gatekeeper2.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA11849 for ; Fri, 15 Mar 2002 15:48:29 +0530 X-SMTP-Sending-IP: 10.2.0.62 Received: from mail.bom.mahindrabt.com by mahindrabt.com ; 12 Mar 2002 15:33:55 +0530 Received: from SOFT.mahindrabt.com ([10.2.4.99]) by mail.bom.mahindrabt.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id g2FAILA25074; Fri, 15 Mar 2002 15:48:21 +0530 Message-ID: <00ba01c1cc0a$5b256080$6304020a@mahindrabt.com> From: "mscansh" To: "Michael Thomas" , "Peterson, Jon" Cc: "'Dean Willis'" , "Sean Olson" , References: <70565611B164D511957A001083FCDD5601870168@va02.va.neustar.com> <15504.49268.508649.869482@thomasm-u1.cisco.com> Subject: Re: [Sip] transport=tls Date: Fri, 15 Mar 2002 15:45:34 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Michael Thomas" To: "Peterson, Jon" Cc: "'Dean Willis'" ; "Sean Olson" ; Sent: Thursday, March 14, 2002 8:53 PM Subject: RE: [Sip] transport=tls > Peterson, Jon writes: > > According to bis09, transport=tls has been deprecated. For the purposes of > > backwards compatibility, the former transport=tls mechanism would be treated > > roughly the same way as the SIPS URI scheme; the two important differences > > are that transport=tls assumes TCP, and that a number of specific rules have > > been mandated for handling the SIPS URI that presumably wouldn't hold for > > transport=tls. > > > > Either of the meanings that Dean alludes to below can be expressed by the > > SIPS URI scheme in varying contexts. The use of SIPS in a Request-URI > > mandates the latter meaning (use TLS for the whole signaling path), while > > use in contexts such as a Record-Route, a Contact address of a registration, > > or in a preferred NAPTR record can suggest to the use of TLS over particular > > segments of a signaling path. > > So let me get this straight: an INVITE with > To: sips:... should fail if somewhere along > the path the next hop is protected, but just > not with TLS? Somebody needs to remind why this > is a Good Thing. > > Mike > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 08:23:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28145 for ; Fri, 15 Mar 2002 08:23:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20418 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 08:23:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18471; Fri, 15 Mar 2002 08:08:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18440 for ; Fri, 15 Mar 2002 08:08:08 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27798 for ; Fri, 15 Mar 2002 08:08:04 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FD7Yc07889 for ; Fri, 15 Mar 2002 08:07:35 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 13:07:34 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0049923F1@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Brian Williams , "Chen, Xin (Xin)" Cc: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Date: Fri, 15 Mar 2002 13:07:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Brian, It is very nice for the terminal to have that capabilities, nobody stops it. But I don't see how this capabilities relying on the "e2e" status type? You can still apply such negotiation capabilities withou using the status type. But if we have that "e2e" status type, then a call setup will fail because the terminals can not find a common protocol to use, please note, the call fails because there is no common RPOTOCOL not because there is no end to end QOS! If you agree that manyfolks should not depend on any protocol, then I guess you also should agree that a call should not fail because there is no common protocol to be used by UAC and UAS. On the contrast, if we don't have such a status type, then the call setup is free from any actually QoS protocol. I guess all the terminals will always try its best to get some QoS for its call. If the terminal supports a QoS reservation protocol like RSVP, it will always use it or try to negotionate with another terminal to find a common protocol regardless there is a "e2e" status type or not. If they find one, then great, they use it. If they don't, then it is up to the terminals to decide whether they will accept the local QoS or not rather than fail the call immeditetaly. Again, true end to end QoS means the resource has been reserved on all the network routing devices alone the path to another end. It is something lucky to have but can not be assured unless you own all the devices. Going back to manyfolks itself, regarding the sentence below: "B receives RESV messages conforming the reservation." Please answer my questions: Does getting a RSVP RESV message indicate the true end to end QoS is achieved? If yes, how? If no, why should we trust something that we know it is not always true? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Brian Williams [mailto:brian.williams@ericsson.com.au] Sent: 15 March 2002 12:13 To: Chen, Xin (Xin) Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning More comments inline. On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > Hi Brian, > > See inline please, > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 11:11 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > > Hi. > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > Agree! I think the e2e is really useless here. The impression I got from > the > > manyfolks draft is that the only way you can get end to end is using RSVP, > > because getting a RSVP RESV message is the detection point that end to end > > is achieved. What happen that one terminal uses RSVP and another terminal > > uses a protocol called "banana" to do end to end? for sure, this will not > > work in manyfolks. Therefore, the e2e here simply mandates that it works > > only if both terminals using the same QoS reservation protocol. > > So my suggestion is to change the "e2e" parameter to "rsvp", then all the > > SIP terminal will have to implement RSVP and we all get end to end QoS. > I would not agree with chaging e2e to be RSVP. This would mean the > manyfolks draft needs to be updated every time a new protocol is > created. Manyfolks should not depend on the actual protocol in use. > > [XC]I would never agree either, but I see no difference to use "e2e" or > "rsvp" here. > > It would work if A uses RSVP and B uses "banana", as long as there is > some point within the network where RSVP interworks with "banana". If > there is no interworking, then of course the qos preconditions will not > be met because there will be no reply to the RSVP (or the "banana"). > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > interworking between different protocols! That is even worse, if we have 100 > different QoS reservation protocols, then we have to have 100 interworking > points in my network in order to get my SIP terminal work under manyfolks. > Simple question, before you start to devolopement the interwork point, how > do you know which protocol you are going to interwork with? Today is Banana, > tomorrow maybe something else. So, let's give up the "e2e" idea today to > save the cost to develop the interworking point in the future. At present we have one e2e protocol (at least if you are considering IP only, it is always possible that terminals may be using other mechanisms such as ATM too, which can be e2e depending on the network). As additional protocols are added, there becomes a need to negotiate the e2e protocol between terminals, and this can include negotiating using capabilities provided by network equipment. Such negotiation would be performed using a protocol aimed for this negotiation. This concept of multiple building blocks which can be used together is a key strategy for extending capabilities in IP networks, and I see no reason not to apply it here too. > > /brian > > > > > By the way, manyfolks says: > > > > "B receives RESV messages conforming the reservation." > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > aware, > > don't be cheated when getting the RESV message! Therefore, the "e2e" just > > gives the terminal a chance to be cheated, a terminal can never be sure > > whether the end to end QoS achieved unless you are in charge of the RSVP > > admission control for all the routers in the path between UAC and UAS, in > > other words, all the routers on the path are in your local network, in > > another words "e2e" = "local". So, please not to introduce any status type > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > > Sent: 15 March 2002 8:18 > > To: Gonzalo.Camarillo@ericsson.com > > Cc: sip@ietf.org > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > Hello, > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end status > > reflects the status of the end-to-end resource reservation" > > In fact, end-to-end means that both end-users will exchange end-to-end > some > > messages using some protocol in order to reserve resources (this could be > > added for clarification, as it is never said in the draft). > > > > My question: Does "end-to-end" mean here RSVP ? > > If the answer is yes, this is not a very future safe approach for the SDP > > extensions, as other protocols could be defined also. > > If the answer is no, how can I know which protocol will be used for > > end-to-end resource reservation ? > > > > Best regards > > Juan Carlos > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 08:25:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28198 for ; Fri, 15 Mar 2002 08:25:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20493 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 08:25:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18559; Fri, 15 Mar 2002 08:08:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29249 for ; Thu, 14 Mar 2002 21:45:25 -0500 (EST) Received: from mail.szutstar.com ([202.105.137.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09723 for ; Thu, 14 Mar 2002 21:45:15 -0500 (EST) Received: from sznssalbert (pc162_59 [172.16.162.59]) by mail.szutstar.com (8.11.1/8.11.1) with SMTP id g2F2jpA12609 for ; Fri, 15 Mar 2002 10:45:51 +0800 Message-ID: <04e301c1cbcb$58cec4f0$3ba210ac@sznssalbert> From: "albert.wang" To: Date: Fri, 15 Mar 2002 10:44:37 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04E0_01C1CC0E.66E2C2B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Sip] Does sip need a interface like DOM(Document Object Model )? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_04E0_01C1CC0E.66E2C2B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_000_04E0_01C1CC0E.66E2C2B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4zMTAzLjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_04E0_01C1CC0E.66E2C2B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 09:18:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29323 for ; Fri, 15 Mar 2002 09:18:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24129 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 09:18:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22394; Fri, 15 Mar 2002 08:59:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22366 for ; Fri, 15 Mar 2002 08:59:28 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28850 for ; Fri, 15 Mar 2002 08:59:24 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA11085; Fri, 15 Mar 2002 14:58:43 +0100 (MET) Subject: RE: [Sip] Manyfolks: e2e meaning To: "Chen, Xin (Xin)" Cc: Brian Williams , "Chen, Xin (Xin)" , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Date: Fri, 15 Mar 2002 14:58:42 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 14:58:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Xin and Brian, I agree with Xin: e2e means really end-user to end-user, and all the path along, otherwise this cannot work. In case of RSVP, this works because the protocol itself provides some mechanisms to detect if the reservation has gone across a "non-RSVP cloud" (RFC2205, section 2.9) For the time being RSVP is the only protocol in the IP world having these characteristics, but in the future other protocols could be created, as e.g. the NSIS protocol. If any translation is being made somewhere in the network between RSVP and "banana", this can become quite tricky, because it raises a lot of issues: - it should be assumed that the interworking rules can be defined without loss of information - none of the end-users know that there is some kind of translation somewhere in the network - if the translation occurs in the middle of the network (even if this is the worst solution), how the translation point can know that the destination is "banana" aware and not RSVP aware ? - very likely, this translation will be performed when entering or leaving the QoS domain closest to the end-user, but here we are leaving the e2e approach, and we are moving to the segmented approach. In summary, ideally - when I launch a resource reservation, I use the protocol known by my terminal - if this is full end-to-end, I need some mechanism to detect that there is no "hole" in the path; this is foreseen in RSVP, any new "banana" protocol should foresee it also. - starting with the same protocol (no matter if it is RSVP or "banana"), my access network could translate it into another protocol; if any translation occurs in the middle, I don't want to be aware of it, providing that I get the service I'm requesting. - even more, if my terminal is not using any protocol with the access network (e.g., current ADSL) mon access network is maybe using some protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) Aren't we saying here, that finally, there is no so much difference between the end-to-end approach and the segmented approach ? I have problems to see how can this really work. Best regards Juan Carlos "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 Sent by: sip-admin@ietf.org To: Brian Williams , "Chen, Xin (Xin)" cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Hi Brian, It is very nice for the terminal to have that capabilities, nobody stops it. But I don't see how this capabilities relying on the "e2e" status type? You can still apply such negotiation capabilities withou using the status type. But if we have that "e2e" status type, then a call setup will fail because the terminals can not find a common protocol to use, please note, the call fails because there is no common RPOTOCOL not because there is no end to end QOS! If you agree that manyfolks should not depend on any protocol, then I guess you also should agree that a call should not fail because there is no common protocol to be used by UAC and UAS. On the contrast, if we don't have such a status type, then the call setup is free from any actually QoS protocol. I guess all the terminals will always try its best to get some QoS for its call. If the terminal supports a QoS reservation protocol like RSVP, it will always use it or try to negotionate with another terminal to find a common protocol regardless there is a "e2e" status type or not. If they find one, then great, they use it. If they don't, then it is up to the terminals to decide whether they will accept the local QoS or not rather than fail the call immeditetaly. Again, true end to end QoS means the resource has been reserved on all the network routing devices alone the path to another end. It is something lucky to have but can not be assured unless you own all the devices. Going back to manyfolks itself, regarding the sentence below: "B receives RESV messages conforming the reservation." Please answer my questions: Does getting a RSVP RESV message indicate the true end to end QoS is achieved? If yes, how? If no, why should we trust something that we know it is not always true? Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Brian Williams [mailto:brian.williams@ericsson.com.au] Sent: 15 March 2002 12:13 To: Chen, Xin (Xin) Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning More comments inline. On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > Hi Brian, > > See inline please, > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 11:11 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > > Hi. > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > Agree! I think the e2e is really useless here. The impression I got from > the > > manyfolks draft is that the only way you can get end to end is using RSVP, > > because getting a RSVP RESV message is the detection point that end to end > > is achieved. What happen that one terminal uses RSVP and another terminal > > uses a protocol called "banana" to do end to end? for sure, this will not > > work in manyfolks. Therefore, the e2e here simply mandates that it works > > only if both terminals using the same QoS reservation protocol. > > So my suggestion is to change the "e2e" parameter to "rsvp", then all the > > SIP terminal will have to implement RSVP and we all get end to end QoS. > I would not agree with chaging e2e to be RSVP. This would mean the > manyfolks draft needs to be updated every time a new protocol is > created. Manyfolks should not depend on the actual protocol in use. > > [XC]I would never agree either, but I see no difference to use "e2e" or > "rsvp" here. > > It would work if A uses RSVP and B uses "banana", as long as there is > some point within the network where RSVP interworks with "banana". If > there is no interworking, then of course the qos preconditions will not > be met because there will be no reply to the RSVP (or the "banana"). > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > interworking between different protocols! That is even worse, if we have 100 > different QoS reservation protocols, then we have to have 100 interworking > points in my network in order to get my SIP terminal work under manyfolks. > Simple question, before you start to devolopement the interwork point, how > do you know which protocol you are going to interwork with? Today is Banana, > tomorrow maybe something else. So, let's give up the "e2e" idea today to > save the cost to develop the interworking point in the future. At present we have one e2e protocol (at least if you are considering IP only, it is always possible that terminals may be using other mechanisms such as ATM too, which can be e2e depending on the network). As additional protocols are added, there becomes a need to negotiate the e2e protocol between terminals, and this can include negotiating using capabilities provided by network equipment. Such negotiation would be performed using a protocol aimed for this negotiation. This concept of multiple building blocks which can be used together is a key strategy for extending capabilities in IP networks, and I see no reason not to apply it here too. > > /brian > > > > > By the way, manyfolks says: > > > > "B receives RESV messages conforming the reservation." > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > aware, > > don't be cheated when getting the RESV message! Therefore, the "e2e" just > > gives the terminal a chance to be cheated, a terminal can never be sure > > whether the end to end QoS achieved unless you are in charge of the RSVP > > admission control for all the routers in the path between UAC and UAS, in > > other words, all the routers on the path are in your local network, in > > another words "e2e" = "local". So, please not to introduce any status type > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > > Sent: 15 March 2002 8:18 > > To: Gonzalo.Camarillo@ericsson.com > > Cc: sip@ietf.org > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > Hello, > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end status > > reflects the status of the end-to-end resource reservation" > > In fact, end-to-end means that both end-users will exchange end-to-end > some > > messages using some protocol in order to reserve resources (this could be > > added for clarification, as it is never said in the draft). > > > > My question: Does "end-to-end" mean here RSVP ? > > If the answer is yes, this is not a very future safe approach for the SDP > > extensions, as other protocols could be defined also. > > If the answer is no, how can I know which protocol will be used for > > end-to-end resource reservation ? > > > > Best regards > > Juan Carlos > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 09:23:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29489 for ; Fri, 15 Mar 2002 09:23:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA24691 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 09:23:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23444; Fri, 15 Mar 2002 09:08:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23412 for ; Fri, 15 Mar 2002 09:08:54 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29058 for ; Fri, 15 Mar 2002 09:08:50 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 534211E162; Fri, 15 Mar 2002 09:08:52 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA09449; Fri, 15 Mar 2002 09:08:49 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA44559; Fri, 15 Mar 2002 09:08:40 -0500 (EST) Date: Fri, 15 Mar 2002 09:08:40 -0500 (EST) Message-Id: <200203151408.JAA44559@fish.research.att.com> To: salreyca@teleco.upv.es Cc: sip@ietf.org Subject: Re: [Sip] mayfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Salva wrote: > is it allowed to send an answer with preconditions to an offer > that didn't contain them (not even the none option tag)? This is the case that led to my suggestion that a MUST be added to the last paragraph of section 5.1. If the offerer MUST generate the SDP by the rules of 5.1.1 and section 4, then there will be a precondition line containing "none" and the answer can upgrade it. Otherwise, when the offer is made by the UAS, there is no mechanism for the UAC to know whether preconditions were supported or not. (When the offer is made by the UAC, then the Supported header can indicate this, but this doesn't work the other direction). Bill Marshall wtm@research.att.com -----original message----- From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 14:17:08 +0100 Subject: [Sip] mayfolks Hi, is it allowed to send an answer with preconditions to an offer that didn't contain them (not even the none option tag)? thanks Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 09:29:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29814 for ; Fri, 15 Mar 2002 09:29:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25304 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 09:29:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24037; Fri, 15 Mar 2002 09:16:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23964 for ; Fri, 15 Mar 2002 09:16:49 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29280 for ; Fri, 15 Mar 2002 09:16:45 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 133B14CE1B; Fri, 15 Mar 2002 09:16:45 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA09704; Fri, 15 Mar 2002 09:16:41 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA29931; Fri, 15 Mar 2002 09:16:24 -0500 (EST) Date: Fri, 15 Mar 2002 09:16:24 -0500 (EST) Message-Id: <200203151416.JAA29931@fish.research.att.com> To: salreyca@teleco.upv.es Cc: sip@ietf.org Subject: Re: [Sip] question on many-folks-draft05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sending an UPDATE with a new offer is allowed, according to the rules given in the update-02 draft. It would be required by the manyfolks procedures if the caller included a "a=conf" line in the SDP - then the rules in section 7 would require the UAS to send an offer "as soon as allowed by the SIP offer/answer rules." However, the initial answer to an offer contained in the INVITE needs to be in a response related to the INVITE, e.g. a reliable provisional one. Use of UPDATE is not appropriate for the answer. Bill Marshall wtm@research.att.com -----original message----- From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 10:54:52 +0100 Subject: [Sip] question on many-folks-draft05 Hello, There is no example shown in the draft where the callee, receiving the first INVITE, sends an UPDATE to the caller. Is there any reason for this, isn't it allowed? For what I've read, the UPDATE are treated in the same fashion as the request that created the dialog (section 6.2 draft-ietf-sip- update-00 ), in this case an INVITE, and we all know that the callee can send a re-INVITE to modify session parameters. Is it really bound to the request that created the dialog, or should it be bound to the last request received, and not terminated yet? thanks, Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 09:37:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00119 for ; Fri, 15 Mar 2002 09:37:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA26240 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 09:37:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24556; Fri, 15 Mar 2002 09:21:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24528 for ; Fri, 15 Mar 2002 09:21:38 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29443 for ; Fri, 15 Mar 2002 09:21:33 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id B6B1B4CE41; Fri, 15 Mar 2002 09:21:35 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA09822; Fri, 15 Mar 2002 09:21:32 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA85244; Fri, 15 Mar 2002 09:20:52 -0500 (EST) Date: Fri, 15 Mar 2002 09:20:52 -0500 (EST) Message-Id: <200203151420.JAA85244@fish.research.att.com> To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Subject: Re: [Sip] Last Call comments on manyfolks-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I wrote too fast yesterday: > Hopefully the [inserted] text also covers the case where the offer is sent > by the UAS in 183 without mandatory preconditions, and the answer from > the UAC in the PRACK upgrades them to mandatory. The UAS then needs > to send a new offer with the confirm-status attribute, presumably in > another 183 reliable provisional response. Goofed there. The UAS would need to send a new offer with the confirm- status attribute in an UPDATE message, since it can't send a new offer in a subsequent reliable provisional response. But the text to be inserted is still OK, I think. Bill Marshall wtm@research.att.com -----original message----- From: William Marshall Date: Thu, 14 Mar 2002 18:17:11 -0500 (EST) To: Gonzalo.Camarillo@ericsson.com Cc: sip@ietf.org Subject: [Sip] Last Call comments on manyfolks-05 One of the pieces lost in the re-write between manyfolks-03 and -05 is all the spec language about the UAS sending its answer in a 183 (Session Progress) provisional response, and when the UAS needs to include a confirmation request in that answer. When the offer is contained in a 1xx reliable provisional response, the rules already require the answer to be in the PRACK. However, when the offer is in the INVITE, nothing (except for the desire for a working system) is requiring the UAS to send the answer as shown in the examples in section 11. Two cases need to be covered. First, the UAC may need the destination information in order to make its local segmented resource reservation, and to establish the flowspec through firewalls etc. Second, the UAS may need confirmation for any aspect that it can't guarantee itself. I believe that wording the requirement around the second case will also include the first case. I propose the following text be added into section 6, just after the indented motivation paragraph beginning "Note that in this case..." A UAS that is not capable of unilaterally meeting all of the mandatory preconditions MUST include a confirm-status attribute in the SDP (offer or answer) that it sends (see Section 7). Further, an SDP (offer or answer) that contains a confirm-status attribute MUST be sent as soon as allowed by the SIP offer/answer rules. Hopefully the above text also covers the case where the offer is sent by the UAS in 183 without mandatory preconditions, and the answer from the UAC in the PRACK upgrades them to mandatory. The UAS then needs to send a new offer with the confirm-status attribute, presumably in another 183 reliable provisional response. Two other places need spec language. The last paragraph of section 5.1 should contain a MUST: With the transaction status table, the user agent MUST generate the current-status and the desired status lines following the syntax of Section 4 and the rules described below in Section 5.1.1. Also, in section 5.2, in the paragraph after Table 3: Once both tables have been updated, an asnwer MUST be generated following the rules described in Section 5.1.1 and taking into account ..... And, a nit. In section 11.2, SDP1 is generated by A, not B. SDP1: A includes local and remote QoS preconditions in the ..... Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 10:23:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01373 for ; Fri, 15 Mar 2002 10:23:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29931 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 10:23:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26901; Fri, 15 Mar 2002 09:45:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26870 for ; Fri, 15 Mar 2002 09:45:36 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00462 for ; Fri, 15 Mar 2002 09:45:31 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Fri, 15 Mar 2002 15:56:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Sip] question on many-folks-draft05 Reply-to: salreyca@teleco.upv.es Message-ID: <3C9219BE.14017.13F8A96@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT see inline please, On 15 Mar 2002, at 9:16, William Marshall wrote: > Sending an UPDATE with a new offer is allowed, according to > the rules given in the update-02 draft. how should this UPDATE be treated at the caller side (for this transaction taking the UAS role)? as a re-INVITE nested in an INVITE? is this allowed? It would be > required by the manyfolks procedures if the caller included > a "a=conf" line in the SDP - then the rules in section 7 > would require the UAS to send an offer "as soon as allowed > by the SIP offer/answer rules." > > However, the initial answer to an offer contained in the INVITE > needs to be in a response related to the INVITE, e.g. a reliable > provisional one. Use of UPDATE is not appropriate for the answer. how can then the callee inform of the progression of the resource reservation? I am not sure if its allowed more than one offer/answer exchange per transaction. If it is, great, then we can send different offers updating the state from the callee to the caller on 183 rel and getting answers back in PRACK's, but if it's not allowed? note that a 200 OK shouldn't be issued by the callee until resource reservation has succeeded. Salva Rey salreyca@teleco.upv.es > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Salva Rey Calatayud" > To: sip@ietf.org > Date: Fri, 15 Mar 2002 10:54:52 +0100 > Subject: [Sip] question on many-folks-draft05 > > Hello, > > There is no example shown in the draft where the callee, > receiving the first INVITE, sends an UPDATE to the c aller. Is there > any reason for this, isn't it allowed? > > For what I've read, the UPDATE are treated in the same fashion > as the request that created the dialog (section 6.2 draft-ietf-sip- > update-00 ), in this case an INVITE, and we all know that the callee > can send a re-INVITE to modify session parameters. Is it really > bound to the request that created the dialog, or should it be bound > to the last request received, and not terminated yet? > > thanks, > Salva > > ********************************** > Salvador Rey Calatayud, M.Sc. > Siemens AG Room 53521 > salreyca@teleco.upv.es Munich, Perlach > Phone number : +49-16095178051 > ********************************** > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 12:34:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05417 for ; Fri, 15 Mar 2002 12:34:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12421 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 12:34:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07907; Fri, 15 Mar 2002 11:59:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07876 for ; Fri, 15 Mar 2002 11:59:35 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04437 for ; Fri, 15 Mar 2002 11:59:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GT000B01XUFR5@firewall.wcom.com> for sip@ietf.org; Fri, 15 Mar 2002 16:59:03 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GT000AB3XUEG5@firewall.wcom.com>; Fri, 15 Mar 2002 16:59:03 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GT000K01XUC4S@dgismtp03.wcomnet.com>; Fri, 15 Mar 2002 16:59:02 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GT000GK7XTX48@dgismtp03.wcomnet.com>; Fri, 15 Mar 2002 16:58:46 +0000 (GMT) Date: Fri, 15 Mar 2002 10:58:45 -0600 From: Henry Sinnreich Subject: RE: [Sip] Manyfolks: e2e meaning In-reply-to: <475FF955A05DD411980D00508B6D5FB0049923F1@en0033exch001u.uk.lucent.com> To: "'Chen, Xin (Xin)'" , "'Brian Williams'" Cc: Juan-Carlos.Rojas@alcatel.fr, Gonzalo.Camarillo@ericsson.com, sip@ietf.org Message-id: <001601c1cc42$ac13a140$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >Again, true end to end QoS means the resource has been reserved >on all the network routing devices alone the path to another end. >It is something lucky to have but can not be assured unless you own all the devices. Why not use the PSTN - it's all there :-) Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Chen, Xin (Xin) > Sent: Friday, March 15, 2002 7:08 AM > To: Brian Williams; Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; > Gonzalo.Camarillo@ericsson.com; sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > > Hi Brian, > > It is very nice for the terminal to have that capabilities, > nobody stops it. But I don't see how this capabilities > relying on the "e2e" status type? You can still apply such > negotiation capabilities withou using the status type. But if > we have that "e2e" status type, then a call setup will fail > because the terminals can not find a common protocol to use, > please note, the call fails because there is no common > RPOTOCOL not because there is no end to end QOS! If you agree > that manyfolks should not depend on any protocol, then I > guess you also should agree that a call should not fail > because there is no common protocol to be used by UAC and UAS. > > On the contrast, if we don't have such a status type, then > the call setup is free from any actually QoS protocol. I > guess all the terminals will always try its best to get some > QoS for its call. If the terminal supports a QoS reservation > protocol like RSVP, it will always use it or try to > negotionate with another terminal to find a common protocol > regardless there is a "e2e" status type or not. If they find > one, then great, they use it. If they don't, then it is up to > the terminals to decide whether they will accept the local > QoS or not rather than fail the call immeditetaly. > > Again, true end to end QoS means the resource has been > reserved on all the network routing devices alone the path to > another end. It is something lucky to have but can not be > assured unless you own all the devices. > > Going back to manyfolks itself, regarding the sentence below: > > "B receives RESV messages conforming the reservation." > > Please answer my questions: > > Does getting a RSVP RESV message indicate the true end to end > QoS is achieved? If yes, how? If no, why should we trust > something that we know it is not always true? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 12:13 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; > Gonzalo.Camarillo@ericsson.com; sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > > More comments inline. > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > Hi Brian, > > > > See inline please, > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 11:11 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > Hi. > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > Agree! I think the e2e is really useless here. The > impression I got > > > from > > the > > > manyfolks draft is that the only way you can get end to > end is using > RSVP, > > > because getting a RSVP RESV message is the detection > point that end > > > to > end > > > is achieved. What happen that one terminal uses RSVP and another > terminal > > > uses a protocol called "banana" to do end to end? for sure, this > > > will > not > > > work in manyfolks. Therefore, the e2e here simply > mandates that it > > > works only if both terminals using the same QoS reservation > > > protocol. So my suggestion is to change the "e2e" parameter to > > > "rsvp", then all > the > > > SIP terminal will have to implement RSVP and we all get > end to end > > > QoS. > > I would not agree with chaging e2e to be RSVP. This would mean the > > manyfolks draft needs to be updated every time a new protocol is > > created. Manyfolks should not depend on the actual protocol in use. > > > > [XC]I would never agree either, but I see no difference to > use "e2e" > > or "rsvp" here. > > > > It would work if A uses RSVP and B uses "banana", as long > as there is > > some point within the network where RSVP interworks with > "banana". If > > there is no interworking, then of course the qos preconditions will > > not be met because there will be no reply to the RSVP (or the > > "banana"). > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but > depends on > > interworking between different protocols! That is even worse, if we > > have > 100 > > different QoS reservation protocols, then we have to have 100 > > interworking points in my network in order to get my SIP > terminal work > > under manyfolks. Simple question, before you start to > devolopement the > > interwork point, how do you know which protocol you are going to > > interwork with? Today is > Banana, > > tomorrow maybe something else. So, let's give up the "e2e" > idea today > > to save the cost to develop the interworking point in the future. > At present we have one e2e protocol (at least if you are > considering IP only, it is always possible that terminals may > be using other mechanisms such as ATM too, which can be e2e > depending on the network). > > As additional protocols are added, there becomes a need to > negotiate the e2e protocol between terminals, and this can > include negotiating using capabilities provided by network > equipment. Such negotiation would be performed using a > protocol aimed for this negotiation. This concept of multiple > building blocks which can be used together is a key strategy > for extending capabilities in IP networks, and I see no > reason not to apply it here too. > > > > > /brian > > > > > > > > By the way, manyfolks says: > > > > > > "B receives RESV messages conforming the reservation." > > > > > > This is WRONG. Any router will route RESV packets even it is not > > > rsvp > > aware, > > > don't be cheated when getting the RESV message! > Therefore, the "e2e" > just > > > gives the terminal a chance to be cheated, a terminal can > never be > > > sure whether the end to end QoS achieved unless you are > in charge of > > > the RSVP admission control for all the routers in the > path between > > > UAC and UAS, > in > > > other words, all the routers on the path are in your > local network, > > > in another words "e2e" = "local". So, please not to introduce any > > > status > type > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Juan-Carlos.Rojas@alcatel.fr > > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > Sent: 15 March 2002 8:18 > > > To: Gonzalo.Camarillo@ericsson.com > > > Cc: sip@ietf.org > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hello, > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > status > > > reflects the status of the end-to-end resource > reservation" In fact, > > > end-to-end means that both end-users will exchange end-to-end > > some > > > messages using some protocol in order to reserve resources (this > > > could > be > > > added for clarification, as it is never said in the draft). > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > If the answer is yes, this is not a very future safe approach for > > > the > SDP > > > extensions, as other protocols could be defined also. > > > If the answer is no, how can I know which protocol will > be used for > > > end-to-end resource reservation ? > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 12:38:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05579 for ; Fri, 15 Mar 2002 12:38:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12891 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 12:38:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09736; Fri, 15 Mar 2002 12:05:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09705 for ; Fri, 15 Mar 2002 12:05:50 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04621 for ; Fri, 15 Mar 2002 12:05:45 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FH5BS28796; Fri, 15 Mar 2002 11:05:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FH58J08276; Fri, 15 Mar 2002 11:05:09 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA01156; Fri, 15 Mar 2002 11:05:01 -0600 (CST) Message-ID: <3C922A4B.4C457DA@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:07:23 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, we already had a discussion about this some time ago, but here we go again... First of all, the trusting thing that worries you (Chen) so much. As I already explained to you before, the whole SIP protocol, and in general every protocol, is based on trusting that the other end sends you messages that reflect real events. That is, if I am a UAS and I decide to send a 180 Ringing even though I am not alerting the user, it is not a failure in the protocol. It is a failure in the UAS implementation. The same way, if I place in my SDP an IP address that does not exist, you will be sending media to nowhere. Again, that does not mean that the offer/answer model is broken. It only means that my UAC does not work properly. And the same way, if an entity forwards RESV messages to me but does nothing regarding resource reservation, it is not a failure in RSVP nor in manyfolks... I hope you understand this time. About your statement saying that RSVP is the only e2e mechanism. What about ATM networks? A UAS may be able to obtain bidirectional resources for the call, without using RSVP at all. What about my intranet, where I can run a proprietary e2e resource reservation protocol? As Brian stated in a previous note, the manyfolks draft provides a mechanism to express preconditions. It does not intend to provide a mechanism to negotiate QoS protocols. Such a mechanism/protocol is not to be defined by the SIP WG because the knowledge needed to define such a mechanism/protocol is not in the SIP WG. We do not deal with QoS reservation protocols and their negotiation. Other WGs might. I believe that you still do not understand the difference between segmented and e2e. Well, I guess what you want to know is the different between an e2e mechanism and a local reservation mechanism. I will give you an example. If I am a 3G terminal and I establish a PDP context, everything I know is that I have resources in my air interface. The fact that the PDP context has been successfully established does not tell me anything about the rest of the path towards the remote UA. However, if I use an e2e reservation protocol, when the reservation is established, I know that there are resources allocated thru all the path. I know, because you have said that a million times, that you are not going to use the e2e status type... good for you, don't use it. But there are other folks that intend to use it in their networks. Let them implement it if they want. Don't be selfish. I guess you are missunderstanding the status types because you believe that using the segmented status type implies that DiffServ is used in the network. This is not necessarily so. Many people claim that there is enough bandwithd in the backbone of the Internet. The bottelnecks are in the access network. People claiming that may want QoS in their accesses, but they are happy with the best effort service provided by the public Internet. In this case, the segmented status type is appropriate, whereas the e2e status type is not. Hope this helps... Best regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Xin and Brian, > > I agree with Xin: e2e means really end-user to end-user, and all the path > along, otherwise this cannot work. In case of RSVP, this works because the > protocol itself provides some mechanisms to detect if the reservation has > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > For the time being RSVP is the only protocol in the IP world having these > characteristics, but in the future other protocols could be created, as > e.g. the NSIS protocol. > > If any translation is being made somewhere in the network between RSVP and > "banana", this can become quite tricky, because it raises a lot of issues: > - it should be assumed that the interworking rules can be defined without > loss of information > - none of the end-users know that there is some kind of translation > somewhere in the network > - if the translation occurs in the middle of the network (even if this is > the worst solution), how the translation point can know that the > destination is "banana" aware and not RSVP aware ? > - very likely, this translation will be performed when entering or leaving > the QoS domain closest to the end-user, but here we are leaving the e2e > approach, and we are moving to the segmented approach. > > In summary, ideally > - when I launch a resource reservation, I use the protocol known by my > terminal > - if this is full end-to-end, I need some mechanism to detect that there is > no "hole" in the path; this is foreseen in RSVP, any new "banana" protocol > should foresee it also. > - starting with the same protocol (no matter if it is RSVP or "banana"), my > access network could translate it into another protocol; if any translation > occurs in the middle, I don't want to be aware of it, providing that I get > the service I'm requesting. > - even more, if my terminal is not using any protocol with the access > network (e.g., current ADSL) mon access network is maybe using some > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > Aren't we saying here, that finally, there is no so much difference between > the end-to-end approach and the segmented approach ? > I have problems to see how can this really work. > > Best regards > Juan Carlos > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > Sent by: sip-admin@ietf.org > > To: Brian Williams , "Chen, Xin (Xin)" > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > Hi Brian, > > It is very nice for the terminal to have that capabilities, nobody stops > it. > But I don't see how this capabilities relying on the "e2e" status type? > You > can still apply such negotiation capabilities withou using the status type. > But if we have that "e2e" status type, then a call setup will fail because > the terminals can not find a common protocol to use, please note, the call > fails because there is no common RPOTOCOL not because there is no end to > end > QOS! If you agree that manyfolks should not depend on any protocol, then I > guess you also should agree that a call should not fail because there is no > common protocol to be used by UAC and UAS. > > On the contrast, if we don't have such a status type, then the call setup > is > free from any actually QoS protocol. I guess all the terminals will always > try its best to get some QoS for its call. If the terminal supports a QoS > reservation protocol like RSVP, it will always use it or try to negotionate > with another terminal to find a common protocol regardless there is a "e2e" > status type or not. If they find one, then great, they use it. If they > don't, then it is up to the terminals to decide whether they will accept > the > local QoS or not rather than fail the call immeditetaly. > > Again, true end to end QoS means the resource has been reserved on all the > network routing devices alone the path to another end. It is something > lucky > to have but can not be assured unless you own all the devices. > > Going back to manyfolks itself, regarding the sentence below: > > "B receives RESV messages conforming the reservation." > > Please answer my questions: > > Does getting a RSVP RESV message indicate the true end to end QoS is > achieved? If yes, how? > If no, why should we trust something that we know it is not always true? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 12:13 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > More comments inline. > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > Hi Brian, > > > > See inline please, > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 11:11 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > Hi. > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > Agree! I think the e2e is really useless here. The impression I got > from > > the > > > manyfolks draft is that the only way you can get end to end is using > RSVP, > > > because getting a RSVP RESV message is the detection point that end to > end > > > is achieved. What happen that one terminal uses RSVP and another > terminal > > > uses a protocol called "banana" to do end to end? for sure, this will > not > > > work in manyfolks. Therefore, the e2e here simply mandates that it > works > > > only if both terminals using the same QoS reservation protocol. > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > the > > > SIP terminal will have to implement RSVP and we all get end to end QoS. > > I would not agree with chaging e2e to be RSVP. This would mean the > > manyfolks draft needs to be updated every time a new protocol is > > created. Manyfolks should not depend on the actual protocol in use. > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > "rsvp" here. > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > some point within the network where RSVP interworks with "banana". If > > there is no interworking, then of course the qos preconditions will not > > be met because there will be no reply to the RSVP (or the "banana"). > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > interworking between different protocols! That is even worse, if we have > 100 > > different QoS reservation protocols, then we have to have 100 > interworking > > points in my network in order to get my SIP terminal work under > manyfolks. > > Simple question, before you start to devolopement the interwork point, > how > > do you know which protocol you are going to interwork with? Today is > Banana, > > tomorrow maybe something else. So, let's give up the "e2e" idea today to > > save the cost to develop the interworking point in the future. > At present we have one e2e protocol (at least if you are considering IP > only, it is always possible that terminals may be using other mechanisms > such as ATM too, which can be e2e depending on the network). > > As additional protocols are added, there becomes a need to negotiate the > e2e protocol between terminals, and this can include negotiating using > capabilities provided by network equipment. Such negotiation would be > performed using a protocol aimed for this negotiation. This concept of > multiple building blocks which can be used together is a key strategy > for extending capabilities in IP networks, and I see no reason not to > apply it here too. > > > > > /brian > > > > > > > > By the way, manyfolks says: > > > > > > "B receives RESV messages conforming the reservation." > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > aware, > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > just > > > gives the terminal a chance to be cheated, a terminal can never be sure > > > whether the end to end QoS achieved unless you are in charge of the > RSVP > > > admission control for all the routers in the path between UAC and UAS, > in > > > other words, all the routers on the path are in your local network, in > > > another words "e2e" = "local". So, please not to introduce any status > type > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > Sent: 15 March 2002 8:18 > > > To: Gonzalo.Camarillo@ericsson.com > > > Cc: sip@ietf.org > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hello, > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > status > > > reflects the status of the end-to-end resource reservation" > > > In fact, end-to-end means that both end-users will exchange end-to-end > > some > > > messages using some protocol in order to reserve resources (this could > be > > > added for clarification, as it is never said in the draft). > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > If the answer is yes, this is not a very future safe approach for the > SDP > > > extensions, as other protocols could be defined also. > > > If the answer is no, how can I know which protocol will be used for > > > end-to-end resource reservation ? > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 12:39:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05626 for ; Fri, 15 Mar 2002 12:39:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12942 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 12:39:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11378; Fri, 15 Mar 2002 12:26:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11348 for ; Fri, 15 Mar 2002 12:25:58 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05090 for ; Fri, 15 Mar 2002 12:25:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHPPS10027; Fri, 15 Mar 2002 11:25:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHPOY22637; Fri, 15 Mar 2002 11:25:24 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA03017; Fri, 15 Mar 2002 11:25:22 -0600 (CST) Message-ID: <3C922F10.D7C20307@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:27:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Gonzalo.Camarillo@ericsson.com, sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks: the segmented approach Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, inline: Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello, > > The segmented approach defines two tags: local and remote. Are they both > really needed ? > I have the feeling that a single value should be enough, let's say "local". Yours is a valid point of view. However, the point of view of the draft is slightly different. Let's say that I am in a 3G network. I know that the backbone is not a problem, but the radio interface is. Therefore, I want the callee to establish the proper PDP context for this call. I can ask him to do that by using the remote tag. In the next call I migh care only about my access, but it is OK if the callee does not reserve resources in his access network. In this case, as you suggest, you would only need the local tag. Therefore, your proposal would cover the second call, but not the first. And I believe that I have the right to say that if the other end does not reserve resources in his access I do not want to talk to him... you could claim, that the other end could tell you that he has reserved resources when he ha not really done so, but, as I said, that would be a non-compliant UAS. > > For the desired-status, you only need to say "I'm using the segmented > model", that is, I will not send you e2e resource reservation messages, and > therefore each of us has to solve the reservation question independently in > its own access network. > > For the current-status, using a single value means: when I send a > current-status, I'm telling you about what *I did* in *my* access network > for resource reservation. When I receive a current-status, I'm learning > what *you did* in *your* access network for resource reservation. > > By the way, the example in section 9 seems to me a little bit strange. I > agree that you can have several preconditions on the same media stream > (even if for complexity reasons, I guess that most people will use only one > precondition), but can you still use at the same time the e2e approach > *and* the segmented approach for the same media? Can you please explain me > how this can work ? For example, I want to make sure that there are enough resources in the access networks (where the bottlenecks typically are), and I would find desirable, although not essential, to have resources in the backbone as well. Regards, Gonzalo > > Best regards > Juan Carlos -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 12:39:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05642 for ; Fri, 15 Mar 2002 12:39:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12958 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 12:39:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10219; Fri, 15 Mar 2002 12:10:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10190 for ; Fri, 15 Mar 2002 12:10:13 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04723 for ; Fri, 15 Mar 2002 12:10:09 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHA6h29324; Fri, 15 Mar 2002 11:10:06 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHA5J09583; Fri, 15 Mar 2002 11:10:05 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA01571; Fri, 15 Mar 2002 11:10:03 -0600 (CST) Message-ID: <3C922B79.1A3C7E32@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:12:25 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Williams CC: "Chen, Xin (Xin)" , Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org, Henry Sinnreich Subject: Re: [Sip] Manyfolks: e2e meaning References: <475FF955A05DD411980D00508B6D5FB0049923B1@en0033exch001u.uk.lucent.com> <1016194359.2377.19.camel@mindy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > This concept of > multiple building blocks which can be used together is a key strategy > for extending capabilities in IP networks, and I see no reason not to > apply it here too. Exactly! This is the biggest difference between net and bell heads! Right, Henry? ;o) Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 12:48:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05810 for ; Fri, 15 Mar 2002 12:48:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA13228 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 12:48:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12323; Fri, 15 Mar 2002 12:33:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12295 for ; Fri, 15 Mar 2002 12:33:02 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05393 for ; Fri, 15 Mar 2002 12:32:59 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA28427; Fri, 15 Mar 2002 18:32:15 +0100 (MET) Subject: Re: [Sip] Manyfolks: e2e meaning To: Gonzalo Camarillo Cc: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Date: Fri, 15 Mar 2002 18:32:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 18:32:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Thanks for your explanation. I agree with the trusting story, this is not a problem for me. If I come back to my original question: does e2e mean RSVP in current manyfolks ? I understand from your explanation that the answer is NO. Am I right ? In this case, how can I tell the other party what protocol I will use for e2e resource reservation ? I understand that your answer is: this is out of the scope of SIP WG. Am I right ? Here, I have still a problem; in corporate intranets we can expect that everybody is using the same protocol everywhere so maybe you don't need to announce it, but in public networks, this can become quite different if SIP is widely deployed. I'm worried on the fact that I'm able to negotiate the session characteristics, including media components, coding formats, etc, and next I'm unable to setup resources because I don't know what protocol is used by the remote party, so the only method is "trial and error". Am I right? I have no problems to differentiate between the e2e approach and the segmented approach, providing that the definitions are clear. Please see also a related mail asking a question on the segmented approach. Best regards Juan Carlos Gonzalo Camarillo on 15/03/2002 18:07:23 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning Hello, we already had a discussion about this some time ago, but here we go again... First of all, the trusting thing that worries you (Chen) so much. As I already explained to you before, the whole SIP protocol, and in general every protocol, is based on trusting that the other end sends you messages that reflect real events. That is, if I am a UAS and I decide to send a 180 Ringing even though I am not alerting the user, it is not a failure in the protocol. It is a failure in the UAS implementation. The same way, if I place in my SDP an IP address that does not exist, you will be sending media to nowhere. Again, that does not mean that the offer/answer model is broken. It only means that my UAC does not work properly. And the same way, if an entity forwards RESV messages to me but does nothing regarding resource reservation, it is not a failure in RSVP nor in manyfolks... I hope you understand this time. About your statement saying that RSVP is the only e2e mechanism. What about ATM networks? A UAS may be able to obtain bidirectional resources for the call, without using RSVP at all. What about my intranet, where I can run a proprietary e2e resource reservation protocol? As Brian stated in a previous note, the manyfolks draft provides a mechanism to express preconditions. It does not intend to provide a mechanism to negotiate QoS protocols. Such a mechanism/protocol is not to be defined by the SIP WG because the knowledge needed to define such a mechanism/protocol is not in the SIP WG. We do not deal with QoS reservation protocols and their negotiation. Other WGs might. I believe that you still do not understand the difference between segmented and e2e. Well, I guess what you want to know is the different between an e2e mechanism and a local reservation mechanism. I will give you an example. If I am a 3G terminal and I establish a PDP context, everything I know is that I have resources in my air interface. The fact that the PDP context has been successfully established does not tell me anything about the rest of the path towards the remote UA. However, if I use an e2e reservation protocol, when the reservation is established, I know that there are resources allocated thru all the path. I know, because you have said that a million times, that you are not going to use the e2e status type... good for you, don't use it. But there are other folks that intend to use it in their networks. Let them implement it if they want. Don't be selfish. I guess you are missunderstanding the status types because you believe that using the segmented status type implies that DiffServ is used in the network. This is not necessarily so. Many people claim that there is enough bandwithd in the backbone of the Internet. The bottelnecks are in the access network. People claiming that may want QoS in their accesses, but they are happy with the best effort service provided by the public Internet. In this case, the segmented status type is appropriate, whereas the e2e status type is not. Hope this helps... Best regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Xin and Brian, > > I agree with Xin: e2e means really end-user to end-user, and all the path > along, otherwise this cannot work. In case of RSVP, this works because the > protocol itself provides some mechanisms to detect if the reservation has > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > For the time being RSVP is the only protocol in the IP world having these > characteristics, but in the future other protocols could be created, as > e.g. the NSIS protocol. > > If any translation is being made somewhere in the network between RSVP and > "banana", this can become quite tricky, because it raises a lot of issues: > - it should be assumed that the interworking rules can be defined without > loss of information > - none of the end-users know that there is some kind of translation > somewhere in the network > - if the translation occurs in the middle of the network (even if this is > the worst solution), how the translation point can know that the > destination is "banana" aware and not RSVP aware ? > - very likely, this translation will be performed when entering or leaving > the QoS domain closest to the end-user, but here we are leaving the e2e > approach, and we are moving to the segmented approach. > > In summary, ideally > - when I launch a resource reservation, I use the protocol known by my > terminal > - if this is full end-to-end, I need some mechanism to detect that there is > no "hole" in the path; this is foreseen in RSVP, any new "banana" protocol > should foresee it also. > - starting with the same protocol (no matter if it is RSVP or "banana"), my > access network could translate it into another protocol; if any translation > occurs in the middle, I don't want to be aware of it, providing that I get > the service I'm requesting. > - even more, if my terminal is not using any protocol with the access > network (e.g., current ADSL) mon access network is maybe using some > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > Aren't we saying here, that finally, there is no so much difference between > the end-to-end approach and the segmented approach ? > I have problems to see how can this really work. > > Best regards > Juan Carlos > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > Sent by: sip-admin@ietf.org > > To: Brian Williams , "Chen, Xin (Xin)" > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > Hi Brian, > > It is very nice for the terminal to have that capabilities, nobody stops > it. > But I don't see how this capabilities relying on the "e2e" status type? > You > can still apply such negotiation capabilities withou using the status type. > But if we have that "e2e" status type, then a call setup will fail because > the terminals can not find a common protocol to use, please note, the call > fails because there is no common RPOTOCOL not because there is no end to > end > QOS! If you agree that manyfolks should not depend on any protocol, then I > guess you also should agree that a call should not fail because there is no > common protocol to be used by UAC and UAS. > > On the contrast, if we don't have such a status type, then the call setup > is > free from any actually QoS protocol. I guess all the terminals will always > try its best to get some QoS for its call. If the terminal supports a QoS > reservation protocol like RSVP, it will always use it or try to negotionate > with another terminal to find a common protocol regardless there is a "e2e" > status type or not. If they find one, then great, they use it. If they > don't, then it is up to the terminals to decide whether they will accept > the > local QoS or not rather than fail the call immeditetaly. > > Again, true end to end QoS means the resource has been reserved on all the > network routing devices alone the path to another end. It is something > lucky > to have but can not be assured unless you own all the devices. > > Going back to manyfolks itself, regarding the sentence below: > > "B receives RESV messages conforming the reservation." > > Please answer my questions: > > Does getting a RSVP RESV message indicate the true end to end QoS is > achieved? If yes, how? > If no, why should we trust something that we know it is not always true? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 12:13 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > More comments inline. > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > Hi Brian, > > > > See inline please, > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 11:11 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > Hi. > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > Agree! I think the e2e is really useless here. The impression I got > from > > the > > > manyfolks draft is that the only way you can get end to end is using > RSVP, > > > because getting a RSVP RESV message is the detection point that end to > end > > > is achieved. What happen that one terminal uses RSVP and another > terminal > > > uses a protocol called "banana" to do end to end? for sure, this will > not > > > work in manyfolks. Therefore, the e2e here simply mandates that it > works > > > only if both terminals using the same QoS reservation protocol. > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > the > > > SIP terminal will have to implement RSVP and we all get end to end QoS. > > I would not agree with chaging e2e to be RSVP. This would mean the > > manyfolks draft needs to be updated every time a new protocol is > > created. Manyfolks should not depend on the actual protocol in use. > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > "rsvp" here. > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > some point within the network where RSVP interworks with "banana". If > > there is no interworking, then of course the qos preconditions will not > > be met because there will be no reply to the RSVP (or the "banana"). > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > interworking between different protocols! That is even worse, if we have > 100 > > different QoS reservation protocols, then we have to have 100 > interworking > > points in my network in order to get my SIP terminal work under > manyfolks. > > Simple question, before you start to devolopement the interwork point, > how > > do you know which protocol you are going to interwork with? Today is > Banana, > > tomorrow maybe something else. So, let's give up the "e2e" idea today to > > save the cost to develop the interworking point in the future. > At present we have one e2e protocol (at least if you are considering IP > only, it is always possible that terminals may be using other mechanisms > such as ATM too, which can be e2e depending on the network). > > As additional protocols are added, there becomes a need to negotiate the > e2e protocol between terminals, and this can include negotiating using > capabilities provided by network equipment. Such negotiation would be > performed using a protocol aimed for this negotiation. This concept of > multiple building blocks which can be used together is a key strategy > for extending capabilities in IP networks, and I see no reason not to > apply it here too. > > > > > /brian > > > > > > > > By the way, manyfolks says: > > > > > > "B receives RESV messages conforming the reservation." > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > aware, > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > just > > > gives the terminal a chance to be cheated, a terminal can never be sure > > > whether the end to end QoS achieved unless you are in charge of the > RSVP > > > admission control for all the routers in the path between UAC and UAS, > in > > > other words, all the routers on the path are in your local network, in > > > another words "e2e" = "local". So, please not to introduce any status > type > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > Sent: 15 March 2002 8:18 > > > To: Gonzalo.Camarillo@ericsson.com > > > Cc: sip@ietf.org > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hello, > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > status > > > reflects the status of the end-to-end resource reservation" > > > In fact, end-to-end means that both end-users will exchange end-to-end > > some > > > messages using some protocol in order to reserve resources (this could > be > > > added for clarification, as it is never said in the draft). > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > If the answer is yes, this is not a very future safe approach for the > SDP > > > extensions, as other protocols could be defined also. > > > If the answer is no, how can I know which protocol will be used for > > > end-to-end resource reservation ? > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:08:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06307 for ; Fri, 15 Mar 2002 13:08:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15526 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:08:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13530; Fri, 15 Mar 2002 12:51:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13499 for ; Fri, 15 Mar 2002 12:51:49 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05892 for ; Fri, 15 Mar 2002 12:51:47 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHpch22464; Fri, 15 Mar 2002 11:51:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHpbJ19715; Fri, 15 Mar 2002 11:51:37 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05293; Fri, 15 Mar 2002 11:51:35 -0600 (CST) Message-ID: <3C923535.DED0FDA8@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:53:57 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: salreyca@teleco.upv.es CC: sip@ietf.org Subject: Re: [Sip] SDP in unreliable 18x References: <3C91CEEB.30745.1B4138@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Salva Rey Calatayud wrote: > > Hi, > > please see inline at end, > > On 7 Mar 2002, at 22:01, Jonathan Rosenberg wrote: > > > > > > > Christer Holmberg wrote: > > > > > > Hi Bob, > > > > > > > >Now, does this mean I'm not allowed to send an SDP in an UN-reliable > > > > >18x? And, if I do, is it then not regardes as an answer? > > > > > > > > You are allowed to send SDP in an unreliable 1xx. However, it MUST be > > > the > > > > same as the SDP you will send in a 2xx. The key sentence is "That same > > > exact > > > > answer MAY also be placed in any provisional responses sent prior to > > > the > > > > answer." > > > > > > True. But, in this case the UAC is not allowed to send a new offer (eg > > > using > > > UPDATE) before it has received the final response. > > > > Right. The idea was to try and add a semblance of compatibility with > > existing implementations. We want everything to be mapped to a set of > > non-overlapping O/A exchanges. So, the idea is that the SDP in an > > unrealiable 18x, and the SDP in a 2xx, are just the same answer. THus, > > we maintain the property of everything being a series of O/A exchanges, > > but allow a single answer to be present in multiple sip responses. > > > > However, it is NOT allowed, to send an offer in INVITE, an answer in a > > reliable 183, and then repeat the answer in the next reliable 183. Thats > > because the answer has to be in the first reliable response sent back, > > which is the first 183. The SDP in the second 183 would be illegal, > > since it would be an offer, and those can't go in responses after the > > first SDP. > > I don't quite understand why these new offer on th > e reliable 183 > would be illegal. Isn't it conveyed on a reliable delivered message. I > thought that was the only condition for O/A exchanges. or is it that > it's only allowed one O/A exchange per transaction? > It is illegal to avoid glare conditions, where you could not refuse the offer in the provisional response even though you would have sent an UPDATE. The update draft outlines when you can send an offer and how. Regards, Gonzalo > Thanks > Salva > > ********************************** > Salvador Rey Calatayud, M.Sc. > Siemens AG Room 53521 > salreyca@teleco.upv.es Munich, Perlach > Phone number : +49-16095178051 > ********************************** > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:12:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06363 for ; Fri, 15 Mar 2002 13:12:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15621 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:12:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13805; Fri, 15 Mar 2002 12:54:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13701 for ; Fri, 15 Mar 2002 12:53:57 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05930 for ; Fri, 15 Mar 2002 12:53:54 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA00564; Fri, 15 Mar 2002 18:53:15 +0100 (MET) Subject: Re: [Sip] Re: Manyfolks: the segmented approach To: Gonzalo Camarillo Cc: Gonzalo.Camarillo@ericsson.com, sip@ietf.org Date: Fri, 15 Mar 2002 18:53:13 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 18:53:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Concerning your first comment: When I send you a SIP INVITE, I have no knowledge about where you are connected (ADSL, UMTS, etc.), therefore I have no idea on the procedures that you have to perform on your access network, but anyhow, I'm always looking for full end-to-end QoS. Therefore, my understanding of the segmented approach is that I'm telling you that I will not send you messages using a protocol that has to be understood in the backbone (e.g., RSVP), but I'm asking you to do what is required for resource reservation in your access network, if ever you need to do something (but I don't know if you actually need to do something, and I don't care about, I'm only interested in the final result). Is this right in your point of view ? Concerning your comment about the example: Maybe I misunderstood something, but my understanding is that end-to-end means "full end-to-end", that is from end-user to end-user, and in this case, when I use the tag e2e, I'm asking the backbone to do what is requested, but I'm asking you also to do what is needed in your access network. In other words, my understanding is: segmented means maybe to do something on both access networks only, but not in backbone; end-to-end means to do what is needed in the backbone and in both access networks. But maybe I'm wrong. If the tag e2e does not take into account both access networks, then you should not say "end-to-end" but maybe "edge-to-edge". I prefer by far the first approach. Best regards Juan Carlos Gonzalo Camarillo @ietf.org on 15/03/2002 18:27:44 Sent by: sip-admin@ietf.org To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: [Sip] Re: Manyfolks: the segmented approach Hi, inline: Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello, > > The segmented approach defines two tags: local and remote. Are they both > really needed ? > I have the feeling that a single value should be enough, let's say "local". Yours is a valid point of view. However, the point of view of the draft is slightly different. Let's say that I am in a 3G network. I know that the backbone is not a problem, but the radio interface is. Therefore, I want the callee to establish the proper PDP context for this call. I can ask him to do that by using the remote tag. In the next call I migh care only about my access, but it is OK if the callee does not reserve resources in his access network. In this case, as you suggest, you would only need the local tag. Therefore, your proposal would cover the second call, but not the first. And I believe that I have the right to say that if the other end does not reserve resources in his access I do not want to talk to him... you could claim, that the other end could tell you that he has reserved resources when he ha not really done so, but, as I said, that would be a non-compliant UAS. > > For the desired-status, you only need to say "I'm using the segmented > model", that is, I will not send you e2e resource reservation messages, and > therefore each of us has to solve the reservation question independently in > its own access network. > > For the current-status, using a single value means: when I send a > current-status, I'm telling you about what *I did* in *my* access network > for resource reservation. When I receive a current-status, I'm learning > what *you did* in *your* access network for resource reservation. > > By the way, the example in section 9 seems to me a little bit strange. I > agree that you can have several preconditions on the same media stream > (even if for complexity reasons, I guess that most people will use only one > precondition), but can you still use at the same time the e2e approach > *and* the segmented approach for the same media? Can you please explain me > how this can work ? For example, I want to make sure that there are enough resources in the access networks (where the bottlenecks typically are), and I would find desirable, although not essential, to have resources in the backbone as well. Regards, Gonzalo > > Best regards > Juan Carlos -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 13:13:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06403 for ; Fri, 15 Mar 2002 13:13:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15740 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:13:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13272; Fri, 15 Mar 2002 12:48:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13240 for ; Fri, 15 Mar 2002 12:48:37 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05822 for ; Fri, 15 Mar 2002 12:48:35 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHlxS22176; Fri, 15 Mar 2002 11:47:59 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHlwH06645; Fri, 15 Mar 2002 11:47:59 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA04978; Fri, 15 Mar 2002 11:47:53 -0600 (CST) Message-ID: <3C923457.DDF224BA@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:50:15 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Thanks for your explanation. I agree with the trusting story, this is not a > problem for me. > > If I come back to my original question: does e2e mean RSVP in current > manyfolks ? > I understand from your explanation that the answer is NO. Am I right ? > You are right. > In this case, how can I tell the other party what protocol I will use for > e2e resource reservation ? > I understand that your answer is: this is out of the scope of SIP WG. Am I > right ? You are right. > Here, I have still a problem; in corporate intranets we can expect that > everybody is using the same protocol everywhere so maybe you don't need to > announce it, but in public networks, this can become quite different if SIP > is widely deployed. > I'm worried on the fact that I'm able to negotiate the session > characteristics, including media components, coding formats, etc, and next > I'm unable to setup resources because I don't know what protocol is used by > the remote party, so the only method is "trial and error". Am I right? The negotiation mechanism is outside the scope of the SIP WG. You can think that if another WG comes up with a protocol to negotiate QoS parameters (including the protocol to use), a UAS will use that protocol upon reception of an SDP including preconditions. This is not that much different from the security stuff. MIKEY (which at the end of the day is a different protocol than SIP) is used to negotiate the security stuff... and MIKEY was not defined in the SIP WG. Regards, Gonzalo > > I have no problems to differentiate between the e2e approach and the > segmented approach, providing that the definitions are clear. Please see > also a related mail asking a question on the segmented approach. > > Best regards > Juan Carlos > > Gonzalo Camarillo on 15/03/2002 > 18:07:23 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: "Chen, Xin (Xin)" , Brian Williams > , Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: Re: [Sip] Manyfolks: e2e meaning > > Hello, > > we already had a discussion about this some time ago, but here we go > again... > > First of all, the trusting thing that worries you (Chen) so much. As I > already explained to you before, the whole SIP protocol, and in general > every protocol, is based on trusting that the other end sends you > messages that reflect real events. That is, if I am a UAS and I decide > to send a 180 Ringing even though I am not alerting the user, it is not > a failure in the protocol. It is a failure in the UAS implementation. > > The same way, if I place in my SDP an IP address that does not exist, > you will be sending media to nowhere. Again, that does not mean that the > offer/answer model is broken. It only means that my UAC does not work > properly. > > And the same way, if an entity forwards RESV messages to me but does > nothing regarding resource reservation, it is not a failure in RSVP nor > in manyfolks... I hope you understand this time. > > About your statement saying that RSVP is the only e2e mechanism. What > about ATM networks? A UAS may be able to obtain bidirectional resources > for the call, without using RSVP at all. What about my intranet, where > I can run a proprietary e2e resource reservation protocol? > > As Brian stated in a previous note, the manyfolks draft provides a > mechanism to express preconditions. It does not intend to provide a > mechanism to negotiate QoS protocols. Such a mechanism/protocol is not > to be defined by the SIP WG because the knowledge needed to define such > a mechanism/protocol is not in the SIP WG. We do not deal with QoS > reservation protocols and their negotiation. Other WGs might. > > I believe that you still do not understand the difference between > segmented and e2e. Well, I guess what you want to know is the different > between an e2e mechanism and a local reservation mechanism. I will give > you an example. If I am a 3G terminal and I establish a PDP context, > everything I know is that I have resources in my air interface. The fact > that the PDP context has been successfully established does not tell me > anything about the rest of the path towards the remote UA. > > However, if I use an e2e reservation protocol, when the reservation is > established, I know that there are resources allocated thru all the > path. > > I know, because you have said that a million times, that you are not > going to use the e2e status type... good for you, don't use it. But > there are other folks that intend to use it in their networks. Let them > implement it if they want. Don't be selfish. > > I guess you are missunderstanding the status types because you believe > that using the segmented status type implies that DiffServ is used in > the network. This is not necessarily so. Many people claim that there is > enough bandwithd in the backbone of the Internet. The bottelnecks are in > the access network. People claiming that may want QoS in their accesses, > but they are happy with the best effort service provided by the public > Internet. In this case, the segmented status type is appropriate, > whereas the e2e status type is not. Hope this helps... > > Best regards, > > Gonzalo > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hi Xin and Brian, > > > > I agree with Xin: e2e means really end-user to end-user, and all the path > > along, otherwise this cannot work. In case of RSVP, this works because > the > > protocol itself provides some mechanisms to detect if the reservation has > > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > > For the time being RSVP is the only protocol in the IP world having these > > characteristics, but in the future other protocols could be created, as > > e.g. the NSIS protocol. > > > > If any translation is being made somewhere in the network between RSVP > and > > "banana", this can become quite tricky, because it raises a lot of > issues: > > - it should be assumed that the interworking rules can be defined without > > loss of information > > - none of the end-users know that there is some kind of translation > > somewhere in the network > > - if the translation occurs in the middle of the network (even if this is > > the worst solution), how the translation point can know that the > > destination is "banana" aware and not RSVP aware ? > > - very likely, this translation will be performed when entering or > leaving > > the QoS domain closest to the end-user, but here we are leaving the e2e > > approach, and we are moving to the segmented approach. > > > > In summary, ideally > > - when I launch a resource reservation, I use the protocol known by my > > terminal > > - if this is full end-to-end, I need some mechanism to detect that there > is > > no "hole" in the path; this is foreseen in RSVP, any new "banana" > protocol > > should foresee it also. > > - starting with the same protocol (no matter if it is RSVP or "banana"), > my > > access network could translate it into another protocol; if any > translation > > occurs in the middle, I don't want to be aware of it, providing that I > get > > the service I'm requesting. > > - even more, if my terminal is not using any protocol with the access > > network (e.g., current ADSL) mon access network is maybe using some > > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > > > Aren't we saying here, that finally, there is no so much difference > between > > the end-to-end approach and the segmented approach ? > > I have problems to see how can this really work. > > > > Best regards > > Juan Carlos > > > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > > > Sent by: sip-admin@ietf.org > > > > To: Brian Williams , "Chen, Xin (Xin)" > > > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, > Gonzalo.Camarillo@ericsson.com, > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > Hi Brian, > > > > It is very nice for the terminal to have that capabilities, nobody stops > > it. > > But I don't see how this capabilities relying on the "e2e" status type? > > You > > can still apply such negotiation capabilities withou using the status > type. > > But if we have that "e2e" status type, then a call setup will fail > because > > the terminals can not find a common protocol to use, please note, the > call > > fails because there is no common RPOTOCOL not because there is no end to > > end > > QOS! If you agree that manyfolks should not depend on any protocol, then > I > > guess you also should agree that a call should not fail because there is > no > > common protocol to be used by UAC and UAS. > > > > On the contrast, if we don't have such a status type, then the call setup > > is > > free from any actually QoS protocol. I guess all the terminals will > always > > try its best to get some QoS for its call. If the terminal supports a QoS > > reservation protocol like RSVP, it will always use it or try to > negotionate > > with another terminal to find a common protocol regardless there is a > "e2e" > > status type or not. If they find one, then great, they use it. If they > > don't, then it is up to the terminals to decide whether they will accept > > the > > local QoS or not rather than fail the call immeditetaly. > > > > Again, true end to end QoS means the resource has been reserved on all > the > > network routing devices alone the path to another end. It is something > > lucky > > to have but can not be assured unless you own all the devices. > > > > Going back to manyfolks itself, regarding the sentence below: > > > > "B receives RESV messages conforming the reservation." > > > > Please answer my questions: > > > > Does getting a RSVP RESV message indicate the true end to end QoS is > > achieved? If yes, how? > > If no, why should we trust something that we know it is not always true? > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 12:13 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > More comments inline. > > > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > > Hi Brian, > > > > > > See inline please, > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > > Sent: 15 March 2002 11:11 > > > To: Chen, Xin (Xin) > > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > > sip@ietf.org > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hi. > > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > > Agree! I think the e2e is really useless here. The impression I got > > from > > > the > > > > manyfolks draft is that the only way you can get end to end is using > > RSVP, > > > > because getting a RSVP RESV message is the detection point that end > to > > end > > > > is achieved. What happen that one terminal uses RSVP and another > > terminal > > > > uses a protocol called "banana" to do end to end? for sure, this will > > not > > > > work in manyfolks. Therefore, the e2e here simply mandates that it > > works > > > > only if both terminals using the same QoS reservation protocol. > > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > > the > > > > SIP terminal will have to implement RSVP and we all get end to end > QoS. > > > I would not agree with chaging e2e to be RSVP. This would mean the > > > manyfolks draft needs to be updated every time a new protocol is > > > created. Manyfolks should not depend on the actual protocol in use. > > > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > > "rsvp" here. > > > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > > some point within the network where RSVP interworks with "banana". If > > > there is no interworking, then of course the qos preconditions will not > > > be met because there will be no reply to the RSVP (or the "banana"). > > > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > > interworking between different protocols! That is even worse, if we > have > > 100 > > > different QoS reservation protocols, then we have to have 100 > > interworking > > > points in my network in order to get my SIP terminal work under > > manyfolks. > > > Simple question, before you start to devolopement the interwork point, > > how > > > do you know which protocol you are going to interwork with? Today is > > Banana, > > > tomorrow maybe something else. So, let's give up the "e2e" idea today > to > > > save the cost to develop the interworking point in the future. > > At present we have one e2e protocol (at least if you are considering IP > > only, it is always possible that terminals may be using other mechanisms > > such as ATM too, which can be e2e depending on the network). > > > > As additional protocols are added, there becomes a need to negotiate the > > e2e protocol between terminals, and this can include negotiating using > > capabilities provided by network equipment. Such negotiation would be > > performed using a protocol aimed for this negotiation. This concept of > > multiple building blocks which can be used together is a key strategy > > for extending capabilities in IP networks, and I see no reason not to > > apply it here too. > > > > > > > > /brian > > > > > > > > > > > By the way, manyfolks says: > > > > > > > > "B receives RESV messages conforming the reservation." > > > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > > aware, > > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > > just > > > > gives the terminal a chance to be cheated, a terminal can never be > sure > > > > whether the end to end QoS achieved unless you are in charge of the > > RSVP > > > > admission control for all the routers in the path between UAC and > UAS, > > in > > > > other words, all the routers on the path are in your local network, > in > > > > another words "e2e" = "local". So, please not to introduce any status > > type > > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > > > > Xin Chen > > > > > > > > Lucent Technologies > > > > Tel: +44 1793 883137 > > > > Mobile: +44 7799 034668 > > > > > > > > > > > > -----Original Message----- > > > > From: Juan-Carlos.Rojas@alcatel.fr > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > > Sent: 15 March 2002 8:18 > > > > To: Gonzalo.Camarillo@ericsson.com > > > > Cc: sip@ietf.org > > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > > > > Hello, > > > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > > status > > > > reflects the status of the end-to-end resource reservation" > > > > In fact, end-to-end means that both end-users will exchange > end-to-end > > > some > > > > messages using some protocol in order to reserve resources (this > could > > be > > > > added for clarification, as it is never said in the draft). > > > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > > If the answer is yes, this is not a very future safe approach for the > > SDP > > > > extensions, as other protocols could be defined also. > > > > If the answer is no, how can I know which protocol will be used for > > > > end-to-end resource reservation ? > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:17:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06485 for ; Fri, 15 Mar 2002 13:17:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15983 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:17:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13978; Fri, 15 Mar 2002 12:54:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13905 for ; Fri, 15 Mar 2002 12:54:46 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05967 for ; Fri, 15 Mar 2002 12:54:44 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHsdh24054; Fri, 15 Mar 2002 11:54:39 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHsdY03539; Fri, 15 Mar 2002 11:54:39 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05581; Fri, 15 Mar 2002 11:54:37 -0600 (CST) Message-ID: <3C9235EB.27F042E4@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:56:59 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: salreyca@teleco.upv.es CC: sip@ietf.org Subject: Re: [Sip] question on many-folks-draft05 References: <3C9219BE.14017.13F8A96@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Salva Rey Calatayud wrote: > > see inline please, > > On 15 Mar 2002, at 9:16, William Marshall wrote: > > > Sending an UPDATE with a new offer is allowed, according to > > the rules given in the update-02 draft. > how should this UPDATE be treated at the caller side (for this > transaction taking the UAS role)? as a re-INVITE nested in an > INVITE? is this allowed? > Yes, it is allowed. Read the update draft. > It would be > > required by the manyfolks procedures if the caller included > > a "a=conf" line in the SDP - then the rules in section 7 > > would require the UAS to send an offer "as soon as allowed > > by the SIP offer/answer rules." > > > > However, the initial answer to an offer contained in the INVITE > > needs to be in a response related to the INVITE, e.g. a reliable > > provisional one. Use of UPDATE is not appropriate for the > answer. > how can then the callee inform of the progression of the resource > reservation? I am not sure if its allowed more than one offer/answer > exchange per transaction. If it is, great, then we can send different > offers updating the state from the callee to the caller on 183 rel and > getting answers back in PRACK's, but if it's not allowed? note that > a 200 OK shouldn't be issued by the callee until resource > reservation has succeeded. The callee sends his first offer in a 1xx rel response and then UPDAPTEs are used. Read the update draft. Anyway, in one of the examples it is said that the 200 OK response for the INVITE carries an offer, when it should be said that an UPDATE carries the offer. This has already been reported and I will fix it. Regards, Gonzalo > > Salva Rey > salreyca@teleco.upv.es > > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Salva Rey Calatayud" > > To: sip@ietf.org > > Date: Fri, 15 Mar 2002 10:54:52 +0100 > > Subject: [Sip] question on many-folks-draft05 > > > > Hello, > > > > There is no example shown in the draft where the callee, > > receiving the first INVITE, sends an UPDATE to the c > aller. Is > there > > any reason for this, isn't it allowed? > > > > For what I've read, the UPDATE are treated in the same fashion > > as the request that created the dialog (section 6.2 draft-ietf-sip- > > update-00 ), in this case an INVITE, and we all know that the > callee > > can send a re-INVITE to modify session parameters. Is it really > > bound to the request that created the dialog, or should it be > bound > > to the last request received, and not terminated yet? > > > > thanks, > > Salva > > > > ********************************** > > Salvador Rey Calatayud, M.Sc. > > Siemens AG Room 53521 > > salreyca@teleco.upv.es Munich, Perlach > > Phone number : +49-16095178051 > > ********************************** > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > sip > > Use sipping@ietf.org for new developments on the application of > sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:18:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06504 for ; Fri, 15 Mar 2002 13:18:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16041 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:18:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15037; Fri, 15 Mar 2002 13:01:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15005 for ; Fri, 15 Mar 2002 13:01:48 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06183 for ; Fri, 15 Mar 2002 13:01:45 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FI1ch28223; Fri, 15 Mar 2002 12:01:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FI1bH14646; Fri, 15 Mar 2002 12:01:37 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA06236; Fri, 15 Mar 2002 12:01:32 -0600 (CST) Message-ID: <3C92378A.A77EFB08@lmf.ericsson.se> Date: Fri, 15 Mar 2002 20:03:54 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Re: Manyfolks: the segmented approach References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Concerning your first comment: > When I send you a SIP INVITE, I have no knowledge about where you are > connected (ADSL, UMTS, etc.), therefore I have no idea on the procedures > that you have to perform on your access network, but anyhow, I'm always > looking for full end-to-end QoS. > Therefore, my understanding of the segmented approach is that I'm telling > you that I will not send you messages using a protocol that has to be > understood in the backbone (e.g., RSVP), but I'm asking you to do what is > required for resource reservation in your access network, if ever you need > to do something (but I don't know if you actually need to do something, and > I don't care about, I'm only interested in the final result). > Is this right in your point of view ? Yes. > > Concerning your comment about the example: > Maybe I misunderstood something, but my understanding is that end-to-end > means "full end-to-end", that is from end-user to end-user, and in this > case, when I use the tag e2e, I'm asking the backbone to do what is > requested, but I'm asking you also to do what is needed in your access > network. > In other words, my understanding is: segmented means maybe to do something > on both access networks only, but not in backbone; end-to-end means to do > what is needed in the backbone and in both access networks. > But maybe I'm wrong. If the tag e2e does not take into account both access > networks, then you should not say "end-to-end" but maybe "edge-to-edge". I > prefer by far the first approach. You are not missunderstanding anything here. If I have e2e, I have Qos in the access networks as well. The only difference in the example were the strength tags. I want mandatory QoS in the local and remote segments, but only optional e2e. As a matter of fact, if the e2e strength tag is finally upgraded to mandatory, subsequent offer/answers may get rid of the segmented lines, since they would be covered by the e2e reservation. Regards, Gonzalo > > Best regards > Juan Carlos > > Gonzalo Camarillo @ietf.org on > 15/03/2002 18:27:44 > > Sent by: sip-admin@ietf.org > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: Gonzalo.Camarillo@ericsson.com, sip@ietf.org > Subject: [Sip] Re: Manyfolks: the segmented approach > > Hi, > > inline: > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hello, > > > > The segmented approach defines two tags: local and remote. Are they both > > really needed ? > > I have the feeling that a single value should be enough, let's say > "local". > > Yours is a valid point of view. However, the point of view of the draft > is slightly different. Let's say that I am in a 3G network. I know that > the backbone is not a problem, but the radio interface is. Therefore, I > want the callee to establish the proper PDP context for this call. I can > ask him to do that by using the remote tag. > > In the next call I migh care only about my access, but it is OK if the > callee does not reserve resources in his access network. In this case, > as you suggest, you would only need the local tag. > > Therefore, your proposal would cover the second call, but not the first. > And I believe that I have the right to say that if the other end does > not reserve resources in his access I do not want to talk to him... you > could claim, that the other end could tell you that he has reserved > resources when he ha not really done so, but, as I said, that would be a > non-compliant UAS. > > > > > For the desired-status, you only need to say "I'm using the segmented > > model", that is, I will not send you e2e resource reservation messages, > and > > therefore each of us has to solve the reservation question independently > in > > its own access network. > > > > For the current-status, using a single value means: when I send a > > current-status, I'm telling you about what *I did* in *my* access network > > for resource reservation. When I receive a current-status, I'm learning > > what *you did* in *your* access network for resource reservation. > > > > By the way, the example in section 9 seems to me a little bit strange. I > > agree that you can have several preconditions on the same media stream > > (even if for complexity reasons, I guess that most people will use only > one > > precondition), but can you still use at the same time the e2e approach > > *and* the segmented approach for the same media? Can you please explain > me > > how this can work ? > > For example, I want to make sure that there are enough resources in the > access networks (where the bottlenecks typically are), and I would find > desirable, although not essential, to have resources in the backbone as > well. > > Regards, > > Gonzalo > > > > > Best regards > > Juan Carlos > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:18:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06520 for ; Fri, 15 Mar 2002 13:18:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16056 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:18:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14239; Fri, 15 Mar 2002 12:57:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14212 for ; Fri, 15 Mar 2002 12:57:17 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06061 for ; Fri, 15 Mar 2002 12:57:14 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FHuhS26713; Fri, 15 Mar 2002 11:56:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FHugJ20891; Fri, 15 Mar 2002 11:56:42 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05756; Fri, 15 Mar 2002 11:56:40 -0600 (CST) Message-ID: <3C923666.22B6656E@lmf.ericsson.se> Date: Fri, 15 Mar 2002 19:59:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: salreyca@teleco.upv.es, sip@ietf.org Subject: Re: [Sip] mayfolks References: <200203151408.JAA44559@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi William Marshall wrote: > > Salva wrote: > > is it allowed to send an answer with preconditions to an offer > > that didn't contain them (not even the none option tag)? > > This is the case that led to my suggestion that a MUST be added > to the last paragraph of section 5.1. If the offerer MUST generate > the SDP by the rules of 5.1.1 and section 4, then there will be a > precondition line containing "none" and the answer can upgrade it. > > Otherwise, when the offer is made by the UAS, there is no mechanism > for the UAC to know whether preconditions were supported or not. > (When the offer is made by the UAC, then the Supported header can > indicate this, but this doesn't work the other direction). Exactly. Besides, the supported header does not tell anything about the preconditions types (e.g., qos) supported. Lines with none tags do. Regards, Gonzalo > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Salva Rey Calatayud" > To: sip@ietf.org > Date: Fri, 15 Mar 2002 14:17:08 +0100 > Subject: [Sip] mayfolks > > Hi, > > is it allowed to send an answer with preconditions to an offer > that didn't contain them (not even the none option tag)? > > thanks > Salva > > ********************************** > Salvador Rey Calatayud, M.Sc. > Siemens AG Room 53521 > salreyca@teleco.upv.es Munich, Perlach > Phone number : +49-16095178051 > ********************************** > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 13:23:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06630 for ; Fri, 15 Mar 2002 13:23:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16300 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:23:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15287; Fri, 15 Mar 2002 13:05:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15256 for ; Fri, 15 Mar 2002 13:05:09 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06262 for ; Fri, 15 Mar 2002 13:05:03 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id TAA01477; Fri, 15 Mar 2002 19:04:08 +0100 (MET) Subject: Re: [Sip] Manyfolks: e2e meaning To: Gonzalo Camarillo Cc: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Date: Fri, 15 Mar 2002 19:04:03 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/15/2002 19:04:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Gonzalo, A small clarification: the definition of a protocol for resource reservation and bearer setup, etc., etc. is clearly out of the scope of the SIP WG, and I'm not asking for. My question was only limited to indicate to the remote party, that I will use the e2e feature, and so that I would like to use the protocol "x" to do it. That's all. Best regards Juan Carlos Gonzalo Camarillo @ietf.org on 15/03/2002 18:50:15 Sent by: sip-admin@ietf.org To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning Hello, Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Thanks for your explanation. I agree with the trusting story, this is not a > problem for me. > > If I come back to my original question: does e2e mean RSVP in current > manyfolks ? > I understand from your explanation that the answer is NO. Am I right ? > You are right. > In this case, how can I tell the other party what protocol I will use for > e2e resource reservation ? > I understand that your answer is: this is out of the scope of SIP WG. Am I > right ? You are right. > Here, I have still a problem; in corporate intranets we can expect that > everybody is using the same protocol everywhere so maybe you don't need to > announce it, but in public networks, this can become quite different if SIP > is widely deployed. > I'm worried on the fact that I'm able to negotiate the session > characteristics, including media components, coding formats, etc, and next > I'm unable to setup resources because I don't know what protocol is used by > the remote party, so the only method is "trial and error". Am I right? The negotiation mechanism is outside the scope of the SIP WG. You can think that if another WG comes up with a protocol to negotiate QoS parameters (including the protocol to use), a UAS will use that protocol upon reception of an SDP including preconditions. This is not that much different from the security stuff. MIKEY (which at the end of the day is a different protocol than SIP) is used to negotiate the security stuff... and MIKEY was not defined in the SIP WG. Regards, Gonzalo > > I have no problems to differentiate between the e2e approach and the > segmented approach, providing that the definitions are clear. Please see > also a related mail asking a question on the segmented approach. > > Best regards > Juan Carlos > > Gonzalo Camarillo on 15/03/2002 > 18:07:23 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: "Chen, Xin (Xin)" , Brian Williams > , Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: Re: [Sip] Manyfolks: e2e meaning > > Hello, > > we already had a discussion about this some time ago, but here we go > again... > > First of all, the trusting thing that worries you (Chen) so much. As I > already explained to you before, the whole SIP protocol, and in general > every protocol, is based on trusting that the other end sends you > messages that reflect real events. That is, if I am a UAS and I decide > to send a 180 Ringing even though I am not alerting the user, it is not > a failure in the protocol. It is a failure in the UAS implementation. > > The same way, if I place in my SDP an IP address that does not exist, > you will be sending media to nowhere. Again, that does not mean that the > offer/answer model is broken. It only means that my UAC does not work > properly. > > And the same way, if an entity forwards RESV messages to me but does > nothing regarding resource reservation, it is not a failure in RSVP nor > in manyfolks... I hope you understand this time. > > About your statement saying that RSVP is the only e2e mechanism. What > about ATM networks? A UAS may be able to obtain bidirectional resources > for the call, without using RSVP at all. What about my intranet, where > I can run a proprietary e2e resource reservation protocol? > > As Brian stated in a previous note, the manyfolks draft provides a > mechanism to express preconditions. It does not intend to provide a > mechanism to negotiate QoS protocols. Such a mechanism/protocol is not > to be defined by the SIP WG because the knowledge needed to define such > a mechanism/protocol is not in the SIP WG. We do not deal with QoS > reservation protocols and their negotiation. Other WGs might. > > I believe that you still do not understand the difference between > segmented and e2e. Well, I guess what you want to know is the different > between an e2e mechanism and a local reservation mechanism. I will give > you an example. If I am a 3G terminal and I establish a PDP context, > everything I know is that I have resources in my air interface. The fact > that the PDP context has been successfully established does not tell me > anything about the rest of the path towards the remote UA. > > However, if I use an e2e reservation protocol, when the reservation is > established, I know that there are resources allocated thru all the > path. > > I know, because you have said that a million times, that you are not > going to use the e2e status type... good for you, don't use it. But > there are other folks that intend to use it in their networks. Let them > implement it if they want. Don't be selfish. > > I guess you are missunderstanding the status types because you believe > that using the segmented status type implies that DiffServ is used in > the network. This is not necessarily so. Many people claim that there is > enough bandwithd in the backbone of the Internet. The bottelnecks are in > the access network. People claiming that may want QoS in their accesses, > but they are happy with the best effort service provided by the public > Internet. In this case, the segmented status type is appropriate, > whereas the e2e status type is not. Hope this helps... > > Best regards, > > Gonzalo > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hi Xin and Brian, > > > > I agree with Xin: e2e means really end-user to end-user, and all the path > > along, otherwise this cannot work. In case of RSVP, this works because > the > > protocol itself provides some mechanisms to detect if the reservation has > > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > > For the time being RSVP is the only protocol in the IP world having these > > characteristics, but in the future other protocols could be created, as > > e.g. the NSIS protocol. > > > > If any translation is being made somewhere in the network between RSVP > and > > "banana", this can become quite tricky, because it raises a lot of > issues: > > - it should be assumed that the interworking rules can be defined without > > loss of information > > - none of the end-users know that there is some kind of translation > > somewhere in the network > > - if the translation occurs in the middle of the network (even if this is > > the worst solution), how the translation point can know that the > > destination is "banana" aware and not RSVP aware ? > > - very likely, this translation will be performed when entering or > leaving > > the QoS domain closest to the end-user, but here we are leaving the e2e > > approach, and we are moving to the segmented approach. > > > > In summary, ideally > > - when I launch a resource reservation, I use the protocol known by my > > terminal > > - if this is full end-to-end, I need some mechanism to detect that there > is > > no "hole" in the path; this is foreseen in RSVP, any new "banana" > protocol > > should foresee it also. > > - starting with the same protocol (no matter if it is RSVP or "banana"), > my > > access network could translate it into another protocol; if any > translation > > occurs in the middle, I don't want to be aware of it, providing that I > get > > the service I'm requesting. > > - even more, if my terminal is not using any protocol with the access > > network (e.g., current ADSL) mon access network is maybe using some > > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > > > Aren't we saying here, that finally, there is no so much difference > between > > the end-to-end approach and the segmented approach ? > > I have problems to see how can this really work. > > > > Best regards > > Juan Carlos > > > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > > > Sent by: sip-admin@ietf.org > > > > To: Brian Williams , "Chen, Xin (Xin)" > > > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, > Gonzalo.Camarillo@ericsson.com, > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > Hi Brian, > > > > It is very nice for the terminal to have that capabilities, nobody stops > > it. > > But I don't see how this capabilities relying on the "e2e" status type? > > You > > can still apply such negotiation capabilities withou using the status > type. > > But if we have that "e2e" status type, then a call setup will fail > because > > the terminals can not find a common protocol to use, please note, the > call > > fails because there is no common RPOTOCOL not because there is no end to > > end > > QOS! If you agree that manyfolks should not depend on any protocol, then > I > > guess you also should agree that a call should not fail because there is > no > > common protocol to be used by UAC and UAS. > > > > On the contrast, if we don't have such a status type, then the call setup > > is > > free from any actually QoS protocol. I guess all the terminals will > always > > try its best to get some QoS for its call. If the terminal supports a QoS > > reservation protocol like RSVP, it will always use it or try to > negotionate > > with another terminal to find a common protocol regardless there is a > "e2e" > > status type or not. If they find one, then great, they use it. If they > > don't, then it is up to the terminals to decide whether they will accept > > the > > local QoS or not rather than fail the call immeditetaly. > > > > Again, true end to end QoS means the resource has been reserved on all > the > > network routing devices alone the path to another end. It is something > > lucky > > to have but can not be assured unless you own all the devices. > > > > Going back to manyfolks itself, regarding the sentence below: > > > > "B receives RESV messages conforming the reservation." > > > > Please answer my questions: > > > > Does getting a RSVP RESV message indicate the true end to end QoS is > > achieved? If yes, how? > > If no, why should we trust something that we know it is not always true? > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 12:13 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > More comments inline. > > > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > > Hi Brian, > > > > > > See inline please, > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > > Sent: 15 March 2002 11:11 > > > To: Chen, Xin (Xin) > > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > > sip@ietf.org > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hi. > > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > > Agree! I think the e2e is really useless here. The impression I got > > from > > > the > > > > manyfolks draft is that the only way you can get end to end is using > > RSVP, > > > > because getting a RSVP RESV message is the detection point that end > to > > end > > > > is achieved. What happen that one terminal uses RSVP and another > > terminal > > > > uses a protocol called "banana" to do end to end? for sure, this will > > not > > > > work in manyfolks. Therefore, the e2e here simply mandates that it > > works > > > > only if both terminals using the same QoS reservation protocol. > > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > > the > > > > SIP terminal will have to implement RSVP and we all get end to end > QoS. > > > I would not agree with chaging e2e to be RSVP. This would mean the > > > manyfolks draft needs to be updated every time a new protocol is > > > created. Manyfolks should not depend on the actual protocol in use. > > > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > > "rsvp" here. > > > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > > some point within the network where RSVP interworks with "banana". If > > > there is no interworking, then of course the qos preconditions will not > > > be met because there will be no reply to the RSVP (or the "banana"). > > > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > > interworking between different protocols! That is even worse, if we > have > > 100 > > > different QoS reservation protocols, then we have to have 100 > > interworking > > > points in my network in order to get my SIP terminal work under > > manyfolks. > > > Simple question, before you start to devolopement the interwork point, > > how > > > do you know which protocol you are going to interwork with? Today is > > Banana, > > > tomorrow maybe something else. So, let's give up the "e2e" idea today > to > > > save the cost to develop the interworking point in the future. > > At present we have one e2e protocol (at least if you are considering IP > > only, it is always possible that terminals may be using other mechanisms > > such as ATM too, which can be e2e depending on the network). > > > > As additional protocols are added, there becomes a need to negotiate the > > e2e protocol between terminals, and this can include negotiating using > > capabilities provided by network equipment. Such negotiation would be > > performed using a protocol aimed for this negotiation. This concept of > > multiple building blocks which can be used together is a key strategy > > for extending capabilities in IP networks, and I see no reason not to > > apply it here too. > > > > > > > > /brian > > > > > > > > > > > By the way, manyfolks says: > > > > > > > > "B receives RESV messages conforming the reservation." > > > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > > aware, > > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > > just > > > > gives the terminal a chance to be cheated, a terminal can never be > sure > > > > whether the end to end QoS achieved unless you are in charge of the > > RSVP > > > > admission control for all the routers in the path between UAC and > UAS, > > in > > > > other words, all the routers on the path are in your local network, > in > > > > another words "e2e" = "local". So, please not to introduce any status > > type > > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > > > > Xin Chen > > > > > > > > Lucent Technologies > > > > Tel: +44 1793 883137 > > > > Mobile: +44 7799 034668 > > > > > > > > > > > > -----Original Message----- > > > > From: Juan-Carlos.Rojas@alcatel.fr > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > > Sent: 15 March 2002 8:18 > > > > To: Gonzalo.Camarillo@ericsson.com > > > > Cc: sip@ietf.org > > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > > > > Hello, > > > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > > status > > > > reflects the status of the end-to-end resource reservation" > > > > In fact, end-to-end means that both end-users will exchange > end-to-end > > > some > > > > messages using some protocol in order to reserve resources (this > could > > be > > > > added for clarification, as it is never said in the draft). > > > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > > If the answer is yes, this is not a very future safe approach for the > > SDP > > > > extensions, as other protocols could be defined also. > > > > If the answer is no, how can I know which protocol will be used for > > > > end-to-end resource reservation ? > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 13:30:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06763 for ; Fri, 15 Mar 2002 13:30:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16824 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 13:30:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15685; Fri, 15 Mar 2002 13:13:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15654 for ; Fri, 15 Mar 2002 13:13:24 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06395 for ; Fri, 15 Mar 2002 13:13:22 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FIClS04708; Fri, 15 Mar 2002 12:12:47 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FICkY10562; Fri, 15 Mar 2002 12:12:46 -0600 (CST) Received: from lmf.ericsson.se (racom160247.am.ericsson.se [138.85.160.247]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA07197; Fri, 15 Mar 2002 12:12:40 -0600 (CST) Message-ID: <3C923A25.5D791603@lmf.ericsson.se> Date: Fri, 15 Mar 2002 20:15:01 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: "Chen, Xin (Xin)" , Brian Williams , sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Juan-Carlos.Rojas@alcatel.fr wrote: > > Gonzalo, > > A small clarification: the definition of a protocol for resource > reservation and bearer setup, etc., etc. is clearly out of the scope of the > SIP WG, and I'm not asking for. > My question was only limited to indicate to the remote party, that I will > use the e2e feature, and so that I would like to use the protocol "x" to do > it. That's all. > Yes, I understand what you want. You want something like the offer answer model. I support these codecs (reservation protocols), I support these ones, so let's use one that we both support. It came out that the offer/answer model was not that easy to be defined, and it may happen that this is not that easy either. Therefore, a WG with the proper competence will do it if necessary (the same way that MMUSIC defined the offer/answer model). But for the time being, it seems that many people find the lightweight approach of the manyfolks draft as an advantage. Regards, Gonzalo > Best regards > Juan Carlos > > Gonzalo Camarillo @ietf.org on > 15/03/2002 18:50:15 > > Sent by: sip-admin@ietf.org > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: "Chen, Xin (Xin)" , Brian Williams > , Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: Re: [Sip] Manyfolks: e2e meaning > > Hello, > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hi Gonzalo, > > > > Thanks for your explanation. I agree with the trusting story, this is not > a > > problem for me. > > > > If I come back to my original question: does e2e mean RSVP in current > > manyfolks ? > > I understand from your explanation that the answer is NO. Am I right ? > > > > You are right. > > > In this case, how can I tell the other party what protocol I will use for > > e2e resource reservation ? > > I understand that your answer is: this is out of the scope of SIP WG. Am > I > > right ? > > You are right. > > > Here, I have still a problem; in corporate intranets we can expect that > > everybody is using the same protocol everywhere so maybe you don't need > to > > announce it, but in public networks, this can become quite different if > SIP > > is widely deployed. > > I'm worried on the fact that I'm able to negotiate the session > > characteristics, including media components, coding formats, etc, and > next > > I'm unable to setup resources because I don't know what protocol is used > by > > the remote party, so the only method is "trial and error". Am I right? > > The negotiation mechanism is outside the scope of the SIP WG. You can > think that if another WG comes up with a protocol to negotiate QoS > parameters (including the protocol to use), a UAS will use that protocol > upon reception of an SDP including preconditions. > > This is not that much different from the security stuff. MIKEY (which at > the end of the day is a different protocol than SIP) is used to > negotiate the security stuff... and MIKEY was not defined in the SIP WG. > > Regards, > > Gonzalo > > > > > I have no problems to differentiate between the e2e approach and the > > segmented approach, providing that the definitions are clear. Please see > > also a related mail asking a question on the segmented approach. > > > > Best regards > > Juan Carlos > > > > Gonzalo Camarillo on 15/03/2002 > > 18:07:23 > > > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > > cc: "Chen, Xin (Xin)" , Brian Williams > > , Gonzalo.Camarillo@ericsson.com, > > sip@ietf.org > > Subject: Re: [Sip] Manyfolks: e2e meaning > > > > Hello, > > > > we already had a discussion about this some time ago, but here we go > > again... > > > > First of all, the trusting thing that worries you (Chen) so much. As I > > already explained to you before, the whole SIP protocol, and in general > > every protocol, is based on trusting that the other end sends you > > messages that reflect real events. That is, if I am a UAS and I decide > > to send a 180 Ringing even though I am not alerting the user, it is not > > a failure in the protocol. It is a failure in the UAS implementation. > > > > The same way, if I place in my SDP an IP address that does not exist, > > you will be sending media to nowhere. Again, that does not mean that the > > offer/answer model is broken. It only means that my UAC does not work > > properly. > > > > And the same way, if an entity forwards RESV messages to me but does > > nothing regarding resource reservation, it is not a failure in RSVP nor > > in manyfolks... I hope you understand this time. > > > > About your statement saying that RSVP is the only e2e mechanism. What > > about ATM networks? A UAS may be able to obtain bidirectional resources > > for the call, without using RSVP at all. What about my intranet, where > > I can run a proprietary e2e resource reservation protocol? > > > > As Brian stated in a previous note, the manyfolks draft provides a > > mechanism to express preconditions. It does not intend to provide a > > mechanism to negotiate QoS protocols. Such a mechanism/protocol is not > > to be defined by the SIP WG because the knowledge needed to define such > > a mechanism/protocol is not in the SIP WG. We do not deal with QoS > > reservation protocols and their negotiation. Other WGs might. > > > > I believe that you still do not understand the difference between > > segmented and e2e. Well, I guess what you want to know is the different > > between an e2e mechanism and a local reservation mechanism. I will give > > you an example. If I am a 3G terminal and I establish a PDP context, > > everything I know is that I have resources in my air interface. The fact > > that the PDP context has been successfully established does not tell me > > anything about the rest of the path towards the remote UA. > > > > However, if I use an e2e reservation protocol, when the reservation is > > established, I know that there are resources allocated thru all the > > path. > > > > I know, because you have said that a million times, that you are not > > going to use the e2e status type... good for you, don't use it. But > > there are other folks that intend to use it in their networks. Let them > > implement it if they want. Don't be selfish. > > > > I guess you are missunderstanding the status types because you believe > > that using the segmented status type implies that DiffServ is used in > > the network. This is not necessarily so. Many people claim that there is > > enough bandwithd in the backbone of the Internet. The bottelnecks are in > > the access network. People claiming that may want QoS in their accesses, > > but they are happy with the best effort service provided by the public > > Internet. In this case, the segmented status type is appropriate, > > whereas the e2e status type is not. Hope this helps... > > > > Best regards, > > > > Gonzalo > > > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > > > Hi Xin and Brian, > > > > > > I agree with Xin: e2e means really end-user to end-user, and all the > path > > > along, otherwise this cannot work. In case of RSVP, this works because > > the > > > protocol itself provides some mechanisms to detect if the reservation > has > > > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > > > For the time being RSVP is the only protocol in the IP world having > these > > > characteristics, but in the future other protocols could be created, as > > > e.g. the NSIS protocol. > > > > > > If any translation is being made somewhere in the network between RSVP > > and > > > "banana", this can become quite tricky, because it raises a lot of > > issues: > > > - it should be assumed that the interworking rules can be defined > without > > > loss of information > > > - none of the end-users know that there is some kind of translation > > > somewhere in the network > > > - if the translation occurs in the middle of the network (even if this > is > > > the worst solution), how the translation point can know that the > > > destination is "banana" aware and not RSVP aware ? > > > - very likely, this translation will be performed when entering or > > leaving > > > the QoS domain closest to the end-user, but here we are leaving the e2e > > > approach, and we are moving to the segmented approach. > > > > > > In summary, ideally > > > - when I launch a resource reservation, I use the protocol known by my > > > terminal > > > - if this is full end-to-end, I need some mechanism to detect that > there > > is > > > no "hole" in the path; this is foreseen in RSVP, any new "banana" > > protocol > > > should foresee it also. > > > - starting with the same protocol (no matter if it is RSVP or > "banana"), > > my > > > access network could translate it into another protocol; if any > > translation > > > occurs in the middle, I don't want to be aware of it, providing that I > > get > > > the service I'm requesting. > > > - even more, if my terminal is not using any protocol with the access > > > network (e.g., current ADSL) mon access network is maybe using some > > > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > > > > > Aren't we saying here, that finally, there is no so much difference > > between > > > the end-to-end approach and the segmented approach ? > > > I have problems to see how can this really work. > > > > > > Best regards > > > Juan Carlos > > > > > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > > > > > Sent by: sip-admin@ietf.org > > > > > > To: Brian Williams , "Chen, Xin > (Xin)" > > > > > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, > > Gonzalo.Camarillo@ericsson.com, > > > sip@ietf.org > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > Hi Brian, > > > > > > It is very nice for the terminal to have that capabilities, nobody > stops > > > it. > > > But I don't see how this capabilities relying on the "e2e" status > type? > > > You > > > can still apply such negotiation capabilities withou using the status > > type. > > > But if we have that "e2e" status type, then a call setup will fail > > because > > > the terminals can not find a common protocol to use, please note, the > > call > > > fails because there is no common RPOTOCOL not because there is no end > to > > > end > > > QOS! If you agree that manyfolks should not depend on any protocol, > then > > I > > > guess you also should agree that a call should not fail because there > is > > no > > > common protocol to be used by UAC and UAS. > > > > > > On the contrast, if we don't have such a status type, then the call > setup > > > is > > > free from any actually QoS protocol. I guess all the terminals will > > always > > > try its best to get some QoS for its call. If the terminal supports a > QoS > > > reservation protocol like RSVP, it will always use it or try to > > negotionate > > > with another terminal to find a common protocol regardless there is a > > "e2e" > > > status type or not. If they find one, then great, they use it. If they > > > don't, then it is up to the terminals to decide whether they will > accept > > > the > > > local QoS or not rather than fail the call immeditetaly. > > > > > > Again, true end to end QoS means the resource has been reserved on all > > the > > > network routing devices alone the path to another end. It is something > > > lucky > > > to have but can not be assured unless you own all the devices. > > > > > > Going back to manyfolks itself, regarding the sentence below: > > > > > > "B receives RESV messages conforming the reservation." > > > > > > Please answer my questions: > > > > > > Does getting a RSVP RESV message indicate the true end to end QoS is > > > achieved? If yes, how? > > > If no, why should we trust something that we know it is not always > true? > > > > > > Thanks > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > > Sent: 15 March 2002 12:13 > > > To: Chen, Xin (Xin) > > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > > sip@ietf.org > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > More comments inline. > > > > > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > > > Hi Brian, > > > > > > > > See inline please, > > > > > > > > Xin Chen > > > > > > > > Lucent Technologies > > > > Tel: +44 1793 883137 > > > > Mobile: +44 7799 034668 > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > > > Sent: 15 March 2002 11:11 > > > > To: Chen, Xin (Xin) > > > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > > > sip@ietf.org > > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > > > > > > > Hi. > > > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > > > Agree! I think the e2e is really useless here. The impression I got > > > from > > > > the > > > > > manyfolks draft is that the only way you can get end to end is > using > > > RSVP, > > > > > because getting a RSVP RESV message is the detection point that end > > to > > > end > > > > > is achieved. What happen that one terminal uses RSVP and another > > > terminal > > > > > uses a protocol called "banana" to do end to end? for sure, this > will > > > not > > > > > work in manyfolks. Therefore, the e2e here simply mandates that it > > > works > > > > > only if both terminals using the same QoS reservation protocol. > > > > > So my suggestion is to change the "e2e" parameter to "rsvp", then > all > > > the > > > > > SIP terminal will have to implement RSVP and we all get end to end > > QoS. > > > > I would not agree with chaging e2e to be RSVP. This would mean the > > > > manyfolks draft needs to be updated every time a new protocol is > > > > created. Manyfolks should not depend on the actual protocol in use. > > > > > > > > [XC]I would never agree either, but I see no difference to use "e2e" > or > > > > "rsvp" here. > > > > > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > > > some point within the network where RSVP interworks with "banana". If > > > > there is no interworking, then of course the qos preconditions will > not > > > > be met because there will be no reply to the RSVP (or the "banana"). > > > > > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends > on > > > > interworking between different protocols! That is even worse, if we > > have > > > 100 > > > > different QoS reservation protocols, then we have to have 100 > > > interworking > > > > points in my network in order to get my SIP terminal work under > > > manyfolks. > > > > Simple question, before you start to devolopement the interwork > point, > > > how > > > > do you know which protocol you are going to interwork with? Today is > > > Banana, > > > > tomorrow maybe something else. So, let's give up the "e2e" idea today > > to > > > > save the cost to develop the interworking point in the future. > > > At present we have one e2e protocol (at least if you are considering IP > > > only, it is always possible that terminals may be using other > mechanisms > > > such as ATM too, which can be e2e depending on the network). > > > > > > As additional protocols are added, there becomes a need to negotiate > the > > > e2e protocol between terminals, and this can include negotiating using > > > capabilities provided by network equipment. Such negotiation would be > > > performed using a protocol aimed for this negotiation. This concept of > > > multiple building blocks which can be used together is a key strategy > > > for extending capabilities in IP networks, and I see no reason not to > > > apply it here too. > > > > > > > > > > > /brian > > > > > > > > > > > > > > By the way, manyfolks says: > > > > > > > > > > "B receives RESV messages conforming the reservation." > > > > > > > > > > This is WRONG. Any router will route RESV packets even it is not > rsvp > > > > aware, > > > > > don't be cheated when getting the RESV message! Therefore, the > "e2e" > > > just > > > > > gives the terminal a chance to be cheated, a terminal can never be > > sure > > > > > whether the end to end QoS achieved unless you are in charge of the > > > RSVP > > > > > admission control for all the routers in the path between UAC and > > UAS, > > > in > > > > > other words, all the routers on the path are in your local network, > > in > > > > > another words "e2e" = "local". So, please not to introduce any > status > > > type > > > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > > > > > > > Xin Chen > > > > > > > > > > Lucent Technologies > > > > > Tel: +44 1793 883137 > > > > > Mobile: +44 7799 034668 > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Juan-Carlos.Rojas@alcatel.fr > > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > > > Sent: 15 March 2002 8:18 > > > > > To: Gonzalo.Camarillo@ericsson.com > > > > > Cc: sip@ietf.org > > > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > > > > > > > Hello, > > > > > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > > > status > > > > > reflects the status of the end-to-end resource reservation" > > > > > In fact, end-to-end means that both end-users will exchange > > end-to-end > > > > some > > > > > messages using some protocol in order to reserve resources (this > > could > > > be > > > > > added for clarification, as it is never said in the draft). > > > > > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > > > If the answer is yes, this is not a very future safe approach for > the > > > SDP > > > > > extensions, as other protocols could be defined also. > > > > > If the answer is no, how can I know which protocol will be used for > > > > > end-to-end resource reservation ? > > > > > > > > > > Best regards > > > > > Juan Carlos > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 14:38:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08028 for ; Fri, 15 Mar 2002 14:38:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21050 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 14:38:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19798; Fri, 15 Mar 2002 14:24:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19690 for ; Fri, 15 Mar 2002 14:24:20 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07734 for ; Fri, 15 Mar 2002 14:24:16 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FJNkl15208 for ; Fri, 15 Mar 2002 14:23:47 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 19:23:45 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00499251E@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , Juan-Carlos.Rojas@alcatel.fr Cc: "Chen, Xin (Xin)" , Brian Williams , Gonzalo.Camarillo@ericsson.com, sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Date: Fri, 15 Mar 2002 19:23:44 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Please don't confuse the QoS with the QoS reservation protocol. QoS is the result and the protocol is the method to get the result. But the method can not always get the right result depending on different situation. In manyfolks, the end to end QoS is the result that the terminals want to get, and the RSVP is the method to achieve the result. But the problem of manyfolks I see is it believes that RSVP can always give end to end QoS. It is a very big possiblity that a RSVP RSEV messaage will travel a non-RSVP capable clound (thanks for Brian giving me the reference RFC2205 2.9), when the terminal gets that message, in manyfolks, the terminal or yourself believe that end to end QoS is achieved, but is there really end to end QoS? How does the terminal know that the non-RSVP clound has the enough resources to support the real-time traffic? Of course, it doesn't know, they can only trust the protocol, the message it gets. I am not worrying about the trusting between the terminals, but what I am worrying is that we are still missing the real thing we need--QoS, the result. When the terminals start to exchange traffic, if the non-RSVP clound is very bandwidth limited, their traffic still suffers. I am familiar with the 3GPP SIP architecture, our terminals don't use RSVP, but this is not the reason I object this staturs type. This is not a 3GPP specific issue, but also apply for IETF, becuase I believe that a lot of other terminals don't use RSVP as well. I also believe there are lots of people wanting to has end to end QoS, me too, but I have to say having the stuts type will not make their life better but worse. You keep tell me "there are other folks that intend to use it in their networks. Don't be selfish.", where is the people, at least I have not seen one liking this status type idea yet except you, I would ask you not to be selfish, give the RSVP none support terminals the chance to make a call. Yes, maybe I still don't understand what does end to end QoS mean in your definition. You also keep telling me "The fact that the PDP context has been successfully established does not tell me anything about the rest of the path towards the remote UA.", I really have difficulty to understand why I have to know by using a protocol like RSVP? In your mind, there is only one type of end to end QoS which is achieved by terminal using a QoS reservation protocol. If you and me are both on a 100M ethernet but in different rooms, I don't know where you are and you don't know where I am, we also have end to end QoS, this is another type of end to end QoS which is not achieved by terminal itself but by network pre-given. Yes, for this type of end to end, I don't know anything about your network, but we enjoy the talk using SIP. Unfortunetely, manyfolks only reflects the first type end to end QoS not the second type. I also asked you before to give the definition or reference of "end to end QoS" in manyfolks, I think this is a reasonable request. Since you are teaching me what is end to end QoS, you must understand it very well from some references, so please point it out to me and other readers please. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 15 March 2002 17:07 To: Juan-Carlos.Rojas@alcatel.fr Cc: Chen, Xin (Xin); Brian Williams; Gonzalo.Camarillo@ericsson.com; sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning Hello, we already had a discussion about this some time ago, but here we go again... First of all, the trusting thing that worries you (Chen) so much. As I already explained to you before, the whole SIP protocol, and in general every protocol, is based on trusting that the other end sends you messages that reflect real events. That is, if I am a UAS and I decide to send a 180 Ringing even though I am not alerting the user, it is not a failure in the protocol. It is a failure in the UAS implementation. The same way, if I place in my SDP an IP address that does not exist, you will be sending media to nowhere. Again, that does not mean that the offer/answer model is broken. It only means that my UAC does not work properly. And the same way, if an entity forwards RESV messages to me but does nothing regarding resource reservation, it is not a failure in RSVP nor in manyfolks... I hope you understand this time. About your statement saying that RSVP is the only e2e mechanism. What about ATM networks? A UAS may be able to obtain bidirectional resources for the call, without using RSVP at all. What about my intranet, where I can run a proprietary e2e resource reservation protocol? As Brian stated in a previous note, the manyfolks draft provides a mechanism to express preconditions. It does not intend to provide a mechanism to negotiate QoS protocols. Such a mechanism/protocol is not to be defined by the SIP WG because the knowledge needed to define such a mechanism/protocol is not in the SIP WG. We do not deal with QoS reservation protocols and their negotiation. Other WGs might. I believe that you still do not understand the difference between segmented and e2e. Well, I guess what you want to know is the different between an e2e mechanism and a local reservation mechanism. I will give you an example. If I am a 3G terminal and I establish a PDP context, everything I know is that I have resources in my air interface. The fact that the PDP context has been successfully established does not tell me anything about the rest of the path towards the remote UA. However, if I use an e2e reservation protocol, when the reservation is established, I know that there are resources allocated thru all the path. I know, because you have said that a million times, that you are not going to use the e2e status type... good for you, don't use it. But there are other folks that intend to use it in their networks. Let them implement it if they want. Don't be selfish. I guess you are missunderstanding the status types because you believe that using the segmented status type implies that DiffServ is used in the network. This is not necessarily so. Many people claim that there is enough bandwithd in the backbone of the Internet. The bottelnecks are in the access network. People claiming that may want QoS in their accesses, but they are happy with the best effort service provided by the public Internet. In this case, the segmented status type is appropriate, whereas the e2e status type is not. Hope this helps... Best regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Xin and Brian, > > I agree with Xin: e2e means really end-user to end-user, and all the path > along, otherwise this cannot work. In case of RSVP, this works because the > protocol itself provides some mechanisms to detect if the reservation has > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > For the time being RSVP is the only protocol in the IP world having these > characteristics, but in the future other protocols could be created, as > e.g. the NSIS protocol. > > If any translation is being made somewhere in the network between RSVP and > "banana", this can become quite tricky, because it raises a lot of issues: > - it should be assumed that the interworking rules can be defined without > loss of information > - none of the end-users know that there is some kind of translation > somewhere in the network > - if the translation occurs in the middle of the network (even if this is > the worst solution), how the translation point can know that the > destination is "banana" aware and not RSVP aware ? > - very likely, this translation will be performed when entering or leaving > the QoS domain closest to the end-user, but here we are leaving the e2e > approach, and we are moving to the segmented approach. > > In summary, ideally > - when I launch a resource reservation, I use the protocol known by my > terminal > - if this is full end-to-end, I need some mechanism to detect that there is > no "hole" in the path; this is foreseen in RSVP, any new "banana" protocol > should foresee it also. > - starting with the same protocol (no matter if it is RSVP or "banana"), my > access network could translate it into another protocol; if any translation > occurs in the middle, I don't want to be aware of it, providing that I get > the service I'm requesting. > - even more, if my terminal is not using any protocol with the access > network (e.g., current ADSL) mon access network is maybe using some > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > Aren't we saying here, that finally, there is no so much difference between > the end-to-end approach and the segmented approach ? > I have problems to see how can this really work. > > Best regards > Juan Carlos > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > Sent by: sip-admin@ietf.org > > To: Brian Williams , "Chen, Xin (Xin)" > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Gonzalo.Camarillo@ericsson.com, > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > Hi Brian, > > It is very nice for the terminal to have that capabilities, nobody stops > it. > But I don't see how this capabilities relying on the "e2e" status type? > You > can still apply such negotiation capabilities withou using the status type. > But if we have that "e2e" status type, then a call setup will fail because > the terminals can not find a common protocol to use, please note, the call > fails because there is no common RPOTOCOL not because there is no end to > end > QOS! If you agree that manyfolks should not depend on any protocol, then I > guess you also should agree that a call should not fail because there is no > common protocol to be used by UAC and UAS. > > On the contrast, if we don't have such a status type, then the call setup > is > free from any actually QoS protocol. I guess all the terminals will always > try its best to get some QoS for its call. If the terminal supports a QoS > reservation protocol like RSVP, it will always use it or try to negotionate > with another terminal to find a common protocol regardless there is a "e2e" > status type or not. If they find one, then great, they use it. If they > don't, then it is up to the terminals to decide whether they will accept > the > local QoS or not rather than fail the call immeditetaly. > > Again, true end to end QoS means the resource has been reserved on all the > network routing devices alone the path to another end. It is something > lucky > to have but can not be assured unless you own all the devices. > > Going back to manyfolks itself, regarding the sentence below: > > "B receives RESV messages conforming the reservation." > > Please answer my questions: > > Does getting a RSVP RESV message indicate the true end to end QoS is > achieved? If yes, how? > If no, why should we trust something that we know it is not always true? > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > Sent: 15 March 2002 12:13 > To: Chen, Xin (Xin) > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: RE: [Sip] Manyfolks: e2e meaning > > More comments inline. > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > Hi Brian, > > > > See inline please, > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 11:11 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > Hi. > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > Agree! I think the e2e is really useless here. The impression I got > from > > the > > > manyfolks draft is that the only way you can get end to end is using > RSVP, > > > because getting a RSVP RESV message is the detection point that end to > end > > > is achieved. What happen that one terminal uses RSVP and another > terminal > > > uses a protocol called "banana" to do end to end? for sure, this will > not > > > work in manyfolks. Therefore, the e2e here simply mandates that it > works > > > only if both terminals using the same QoS reservation protocol. > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > the > > > SIP terminal will have to implement RSVP and we all get end to end QoS. > > I would not agree with chaging e2e to be RSVP. This would mean the > > manyfolks draft needs to be updated every time a new protocol is > > created. Manyfolks should not depend on the actual protocol in use. > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > "rsvp" here. > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > some point within the network where RSVP interworks with "banana". If > > there is no interworking, then of course the qos preconditions will not > > be met because there will be no reply to the RSVP (or the "banana"). > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > interworking between different protocols! That is even worse, if we have > 100 > > different QoS reservation protocols, then we have to have 100 > interworking > > points in my network in order to get my SIP terminal work under > manyfolks. > > Simple question, before you start to devolopement the interwork point, > how > > do you know which protocol you are going to interwork with? Today is > Banana, > > tomorrow maybe something else. So, let's give up the "e2e" idea today to > > save the cost to develop the interworking point in the future. > At present we have one e2e protocol (at least if you are considering IP > only, it is always possible that terminals may be using other mechanisms > such as ATM too, which can be e2e depending on the network). > > As additional protocols are added, there becomes a need to negotiate the > e2e protocol between terminals, and this can include negotiating using > capabilities provided by network equipment. Such negotiation would be > performed using a protocol aimed for this negotiation. This concept of > multiple building blocks which can be used together is a key strategy > for extending capabilities in IP networks, and I see no reason not to > apply it here too. > > > > > /brian > > > > > > > > By the way, manyfolks says: > > > > > > "B receives RESV messages conforming the reservation." > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > aware, > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > just > > > gives the terminal a chance to be cheated, a terminal can never be sure > > > whether the end to end QoS achieved unless you are in charge of the > RSVP > > > admission control for all the routers in the path between UAC and UAS, > in > > > other words, all the routers on the path are in your local network, in > > > another words "e2e" = "local". So, please not to introduce any status > type > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Juan-Carlos.Rojas@alcatel.fr > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > Sent: 15 March 2002 8:18 > > > To: Gonzalo.Camarillo@ericsson.com > > > Cc: sip@ietf.org > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hello, > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > status > > > reflects the status of the end-to-end resource reservation" > > > In fact, end-to-end means that both end-users will exchange end-to-end > > some > > > messages using some protocol in order to reserve resources (this could > be > > > added for clarification, as it is never said in the draft). > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > If the answer is yes, this is not a very future safe approach for the > SDP > > > extensions, as other protocols could be defined also. > > > If the answer is no, how can I know which protocol will be used for > > > end-to-end resource reservation ? > > > > > > Best regards > > > Juan Carlos > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 14:47:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08256 for ; Fri, 15 Mar 2002 14:47:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21424 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 14:47:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20760; Fri, 15 Mar 2002 14:33:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20732 for ; Fri, 15 Mar 2002 14:33:11 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07948 for ; Fri, 15 Mar 2002 14:33:07 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FJX3h19105; Fri, 15 Mar 2002 13:33:03 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FJX3G09594; Fri, 15 Mar 2002 13:33:03 -0600 (CST) Received: from lmf.ericsson.se (rmt160241.am.ericsson.se [138.85.160.241]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA14590; Fri, 15 Mar 2002 13:32:57 -0600 (CST) Message-ID: <3C924CF5.6EFAF497@lmf.ericsson.se> Date: Fri, 15 Mar 2002 21:35:17 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: Juan-Carlos.Rojas@alcatel.fr, Brian Williams , sip@ietf.org Subject: Re: [Sip] Manyfolks: e2e meaning References: <475FF955A05DD411980D00508B6D5FB00499251E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Chen, Xin (Xin)" wrote: > > Hi Gonzalo, > > Please don't confuse the QoS with the QoS reservation protocol. QoS is the > result and the protocol is the method to get the result. But the method can > not always get the right result depending on different situation. > > In manyfolks, the end to end QoS is the result that the terminals want to > get, and the RSVP is the method to achieve the result. But the problem of > manyfolks I see is it believes that RSVP can always give end to end QoS. > > It is a very big possiblity that a RSVP RSEV messaage will travel a non-RSVP > capable clound (thanks for Brian giving me the reference RFC2205 2.9), when > the terminal gets that message, in manyfolks, the terminal or yourself > believe that end to end QoS is achieved, but is there really end to end QoS? > How does the terminal know that the non-RSVP clound has the enough resources > to support the real-time traffic? Of course, it doesn't know, they can only > trust the protocol, the message it gets. I am not worrying about the > trusting between the terminals, but what I am worrying is that we are still > missing the real thing we need--QoS, the result. When the terminals start to > exchange traffic, if the non-RSVP clound is very bandwidth limited, their > traffic still suffers. > If a router forwards a RESV message and his network does not have enough resources, it is a problem in that router or in RSVP itself, not in manyfolks. Besides, how many times I have to explain you that RSVP is not the only e2e QoS reservation protocol????? We have already mentioned ATM networks and proprietary reservation protocols. Do I have to explain that again???? > I am familiar with the 3GPP SIP architecture, our terminals don't use RSVP, > but this is not the reason I object this staturs type. Again, RSVP != e2e > This is not a 3GPP > specific issue, but also apply for IETF, becuase I believe that a lot of > other terminals don't use RSVP as well. I also believe there are lots of > people wanting to has end to end QoS, me too, but I have to say having the > stuts type will not make their life better but worse. You keep tell me > "there are other folks that intend to use it in their networks. Don't be > selfish.", where is the people, at least I have not seen one liking this > status type idea yet except you, This is a funny one. If you read the previous versions of manyfolks, which was developed by the DCS guys in the first place, the only status type was e2e. What I have added is the segmented status code that you like so much... give me a break!! > I would ask you not to be selfish, give > the RSVP none support terminals the chance to make a call. > Again, RSVP != e2e > Yes, maybe I still don't understand what does end to end QoS mean in your > definition. You also keep telling me "The fact > that the PDP context has been successfully established does not tell me > anything about the rest of the path towards the remote UA.", I really have > difficulty to understand why I have to know by using a protocol like RSVP? Again, RSVP != e2e. And again, the fact that a router forwards a RESV message without having resources is a problem that belong to that router and to RSVP, not to manyfolks, which is only an enabler. > In your mind, there is only one type of end to end QoS which is achieved by > terminal using a QoS reservation protocol. If you and me are both on a 100M > ethernet but in different rooms, I don't know where you are and you don't > know where I am, we also have end to end QoS, this is another type of end to > end QoS which is not achieved by terminal itself but by network pre-given. Right. In this situation you do not need anything like manyfolks... why should manyfolks cover an scenario where no extra signalling is needed? > Yes, for this type of end to end, I don't know anything about your network, > but we enjoy the talk using SIP. > > Unfortunetely, manyfolks only reflects the first type end to end QoS not the > second type. > > I also asked you before to give the definition or reference of "end to end > QoS" in manyfolks, I think this is a reasonable request. Since you are > teaching me what is end to end QoS, you must understand it very well from > some references, so please point it out to me and other readers please. Propose a definition and if it is sensible it will be added to the draft. Best regards, Gonzalo > > Thanks > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 15 March 2002 17:07 > To: Juan-Carlos.Rojas@alcatel.fr > Cc: Chen, Xin (Xin); Brian Williams; Gonzalo.Camarillo@ericsson.com; > sip@ietf.org > Subject: Re: [Sip] Manyfolks: e2e meaning > > Hello, > > we already had a discussion about this some time ago, but here we go > again... > > First of all, the trusting thing that worries you (Chen) so much. As I > already explained to you before, the whole SIP protocol, and in general > every protocol, is based on trusting that the other end sends you > messages that reflect real events. That is, if I am a UAS and I decide > to send a 180 Ringing even though I am not alerting the user, it is not > a failure in the protocol. It is a failure in the UAS implementation. > > The same way, if I place in my SDP an IP address that does not exist, > you will be sending media to nowhere. Again, that does not mean that the > offer/answer model is broken. It only means that my UAC does not work > properly. > > And the same way, if an entity forwards RESV messages to me but does > nothing regarding resource reservation, it is not a failure in RSVP nor > in manyfolks... I hope you understand this time. > > About your statement saying that RSVP is the only e2e mechanism. What > about ATM networks? A UAS may be able to obtain bidirectional resources > for the call, without using RSVP at all. What about my intranet, where > I can run a proprietary e2e resource reservation protocol? > > As Brian stated in a previous note, the manyfolks draft provides a > mechanism to express preconditions. It does not intend to provide a > mechanism to negotiate QoS protocols. Such a mechanism/protocol is not > to be defined by the SIP WG because the knowledge needed to define such > a mechanism/protocol is not in the SIP WG. We do not deal with QoS > reservation protocols and their negotiation. Other WGs might. > > I believe that you still do not understand the difference between > segmented and e2e. Well, I guess what you want to know is the different > between an e2e mechanism and a local reservation mechanism. I will give > you an example. If I am a 3G terminal and I establish a PDP context, > everything I know is that I have resources in my air interface. The fact > that the PDP context has been successfully established does not tell me > anything about the rest of the path towards the remote UA. > > However, if I use an e2e reservation protocol, when the reservation is > established, I know that there are resources allocated thru all the > path. > > I know, because you have said that a million times, that you are not > going to use the e2e status type... good for you, don't use it. But > there are other folks that intend to use it in their networks. Let them > implement it if they want. Don't be selfish. > > I guess you are missunderstanding the status types because you believe > that using the segmented status type implies that DiffServ is used in > the network. This is not necessarily so. Many people claim that there is > enough bandwithd in the backbone of the Internet. The bottelnecks are in > the access network. People claiming that may want QoS in their accesses, > but they are happy with the best effort service provided by the public > Internet. In this case, the segmented status type is appropriate, > whereas the e2e status type is not. Hope this helps... > > Best regards, > > Gonzalo > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hi Xin and Brian, > > > > I agree with Xin: e2e means really end-user to end-user, and all the path > > along, otherwise this cannot work. In case of RSVP, this works because the > > protocol itself provides some mechanisms to detect if the reservation has > > gone across a "non-RSVP cloud" (RFC2205, section 2.9) > > For the time being RSVP is the only protocol in the IP world having these > > characteristics, but in the future other protocols could be created, as > > e.g. the NSIS protocol. > > > > If any translation is being made somewhere in the network between RSVP and > > "banana", this can become quite tricky, because it raises a lot of issues: > > - it should be assumed that the interworking rules can be defined without > > loss of information > > - none of the end-users know that there is some kind of translation > > somewhere in the network > > - if the translation occurs in the middle of the network (even if this is > > the worst solution), how the translation point can know that the > > destination is "banana" aware and not RSVP aware ? > > - very likely, this translation will be performed when entering or leaving > > the QoS domain closest to the end-user, but here we are leaving the e2e > > approach, and we are moving to the segmented approach. > > > > In summary, ideally > > - when I launch a resource reservation, I use the protocol known by my > > terminal > > - if this is full end-to-end, I need some mechanism to detect that there > is > > no "hole" in the path; this is foreseen in RSVP, any new "banana" protocol > > should foresee it also. > > - starting with the same protocol (no matter if it is RSVP or "banana"), > my > > access network could translate it into another protocol; if any > translation > > occurs in the middle, I don't want to be aware of it, providing that I get > > the service I'm requesting. > > - even more, if my terminal is not using any protocol with the access > > network (e.g., current ADSL) mon access network is maybe using some > > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.) > > > > Aren't we saying here, that finally, there is no so much difference > between > > the end-to-end approach and the segmented approach ? > > I have problems to see how can this really work. > > > > Best regards > > Juan Carlos > > > > "Chen, Xin (Xin)" @ietf.org on 15/03/2002 14:07:32 > > > > Sent by: sip-admin@ietf.org > > > > To: Brian Williams , "Chen, Xin (Xin)" > > > > cc: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, > Gonzalo.Camarillo@ericsson.com, > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > Hi Brian, > > > > It is very nice for the terminal to have that capabilities, nobody stops > > it. > > But I don't see how this capabilities relying on the "e2e" status type? > > You > > can still apply such negotiation capabilities withou using the status > type. > > But if we have that "e2e" status type, then a call setup will fail because > > the terminals can not find a common protocol to use, please note, the call > > fails because there is no common RPOTOCOL not because there is no end to > > end > > QOS! If you agree that manyfolks should not depend on any protocol, then I > > guess you also should agree that a call should not fail because there is > no > > common protocol to be used by UAC and UAS. > > > > On the contrast, if we don't have such a status type, then the call setup > > is > > free from any actually QoS protocol. I guess all the terminals will always > > try its best to get some QoS for its call. If the terminal supports a QoS > > reservation protocol like RSVP, it will always use it or try to > negotionate > > with another terminal to find a common protocol regardless there is a > "e2e" > > status type or not. If they find one, then great, they use it. If they > > don't, then it is up to the terminals to decide whether they will accept > > the > > local QoS or not rather than fail the call immeditetaly. > > > > Again, true end to end QoS means the resource has been reserved on all the > > network routing devices alone the path to another end. It is something > > lucky > > to have but can not be assured unless you own all the devices. > > > > Going back to manyfolks itself, regarding the sentence below: > > > > "B receives RESV messages conforming the reservation." > > > > Please answer my questions: > > > > Does getting a RSVP RESV message indicate the true end to end QoS is > > achieved? If yes, how? > > If no, why should we trust something that we know it is not always true? > > > > Thanks > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > -----Original Message----- > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > Sent: 15 March 2002 12:13 > > To: Chen, Xin (Xin) > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > sip@ietf.org > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > More comments inline. > > > > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote: > > > Hi Brian, > > > > > > See inline please, > > > > > > Xin Chen > > > > > > Lucent Technologies > > > Tel: +44 1793 883137 > > > Mobile: +44 7799 034668 > > > > > > > > > -----Original Message----- > > > From: Brian Williams [mailto:brian.williams@ericsson.com.au] > > > Sent: 15 March 2002 11:11 > > > To: Chen, Xin (Xin) > > > Cc: Juan-Carlos.Rojas@alcatel.fr; Gonzalo.Camarillo@ericsson.com; > > > sip@ietf.org > > > Subject: RE: [Sip] Manyfolks: e2e meaning > > > > > > > > > Hi. > > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote: > > > > Agree! I think the e2e is really useless here. The impression I got > > from > > > the > > > > manyfolks draft is that the only way you can get end to end is using > > RSVP, > > > > because getting a RSVP RESV message is the detection point that end to > > end > > > > is achieved. What happen that one terminal uses RSVP and another > > terminal > > > > uses a protocol called "banana" to do end to end? for sure, this will > > not > > > > work in manyfolks. Therefore, the e2e here simply mandates that it > > works > > > > only if both terminals using the same QoS reservation protocol. > > > > So my suggestion is to change the "e2e" parameter to "rsvp", then all > > the > > > > SIP terminal will have to implement RSVP and we all get end to end > QoS. > > > I would not agree with chaging e2e to be RSVP. This would mean the > > > manyfolks draft needs to be updated every time a new protocol is > > > created. Manyfolks should not depend on the actual protocol in use. > > > > > > [XC]I would never agree either, but I see no difference to use "e2e" or > > > "rsvp" here. > > > > > > It would work if A uses RSVP and B uses "banana", as long as there is > > > some point within the network where RSVP interworks with "banana". If > > > there is no interworking, then of course the qos preconditions will not > > > be met because there will be no reply to the RSVP (or the "banana"). > > > > > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends on > > > interworking between different protocols! That is even worse, if we have > > 100 > > > different QoS reservation protocols, then we have to have 100 > > interworking > > > points in my network in order to get my SIP terminal work under > > manyfolks. > > > Simple question, before you start to devolopement the interwork point, > > how > > > do you know which protocol you are going to interwork with? Today is > > Banana, > > > tomorrow maybe something else. So, let's give up the "e2e" idea today to > > > save the cost to develop the interworking point in the future. > > At present we have one e2e protocol (at least if you are considering IP > > only, it is always possible that terminals may be using other mechanisms > > such as ATM too, which can be e2e depending on the network). > > > > As additional protocols are added, there becomes a need to negotiate the > > e2e protocol between terminals, and this can include negotiating using > > capabilities provided by network equipment. Such negotiation would be > > performed using a protocol aimed for this negotiation. This concept of > > multiple building blocks which can be used together is a key strategy > > for extending capabilities in IP networks, and I see no reason not to > > apply it here too. > > > > > > > > /brian > > > > > > > > > > > By the way, manyfolks says: > > > > > > > > "B receives RESV messages conforming the reservation." > > > > > > > > This is WRONG. Any router will route RESV packets even it is not rsvp > > > aware, > > > > don't be cheated when getting the RESV message! Therefore, the "e2e" > > just > > > > gives the terminal a chance to be cheated, a terminal can never be > sure > > > > whether the end to end QoS achieved unless you are in charge of the > > RSVP > > > > admission control for all the routers in the path between UAC and UAS, > > in > > > > other words, all the routers on the path are in your local network, in > > > > another words "e2e" = "local". So, please not to introduce any status > > type > > > > in manyfolks, they just can not achieve what they want to achieve. > > > > > > > > > > > > Xin Chen > > > > > > > > Lucent Technologies > > > > Tel: +44 1793 883137 > > > > Mobile: +44 7799 034668 > > > > > > > > > > > > -----Original Message----- > > > > From: Juan-Carlos.Rojas@alcatel.fr > > [mailto:Juan-Carlos.Rojas@alcatel.fr] > > > > Sent: 15 March 2002 8:18 > > > > To: Gonzalo.Camarillo@ericsson.com > > > > Cc: sip@ietf.org > > > > Subject: [Sip] Manyfolks: e2e meaning > > > > > > > > > > > > Hello, > > > > > > > > In manyfolks-05, it is said that "status type: ...: The end-to-end > > status > > > > reflects the status of the end-to-end resource reservation" > > > > In fact, end-to-end means that both end-users will exchange end-to-end > > > some > > > > messages using some protocol in order to reserve resources (this could > > be > > > > added for clarification, as it is never said in the draft). > > > > > > > > My question: Does "end-to-end" mean here RSVP ? > > > > If the answer is yes, this is not a very future safe approach for the > > SDP > > > > extensions, as other protocols could be defined also. > > > > If the answer is no, how can I know which protocol will be used for > > > > end-to-end resource reservation ? > > > > > > > > Best regards > > > > Juan Carlos > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Fri Mar 15 15:34:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09570 for ; Fri, 15 Mar 2002 15:34:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24136 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 15:34:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22998; Fri, 15 Mar 2002 15:16:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22967 for ; Fri, 15 Mar 2002 15:16:49 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09228 for ; Fri, 15 Mar 2002 15:16:45 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2FKGFw16236 for ; Fri, 15 Mar 2002 15:16:15 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Mar 2002 20:16:14 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB004992521@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Gonzalo Camarillo , "Chen, Xin (Xin)" Cc: Juan-Carlos.Rojas@alcatel.fr, Brian Williams , sip@ietf.org Subject: RE: [Sip] Manyfolks: e2e meaning Date: Fri, 15 Mar 2002 20:16:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, All the end to end QoS reservation protocols will have the same problem RSVP has unless you own the whole network. Since we know there is a petential problem, why do we introduce this into manyfolks, if we know the information carried by the protocol can not be always true, why our SIP terminals have to always trust it? It will be manyfolks' problem. By the way, previous versions of manyfolks does use RSVP as example, but there was no such "e2e". Also, I think you are the best person to provide the definition, and I think this is important. Because if this is a rule, then all the player have to understand the rule in the same way, otherwise it will not work. And the person who creates this rule will be the person to explain the rule. I only have one minor text propose: Section 5.1: Mandatory: the user agents must provide resource reservation. Otherwise, session establish- ment (must)SHOULD not continue. Thanks Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 16:06:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10324 for ; Fri, 15 Mar 2002 16:06:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26269 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 16:06:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24790; Fri, 15 Mar 2002 15:49:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24712 for ; Fri, 15 Mar 2002 15:49:30 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09961 for ; Fri, 15 Mar 2002 15:46:13 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2FKjjS22733 for ; Fri, 15 Mar 2002 14:45:45 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FKjiN03282 for ; Fri, 15 Mar 2002 14:45:44 -0600 (CST) Received: from lmf.ericsson.se (rmt160241.am.ericsson.se [138.85.160.241]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA22987; Fri, 15 Mar 2002 14:45:42 -0600 (CST) Message-ID: <3C925E01.8D3FE685@lmf.ericsson.se> Date: Fri, 15 Mar 2002 22:48:01 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "George Foti (LMC)" CC: sip References: <32CD630F6CBED411AE180008C7894CBC0C0374A8@lmc37.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Comments maynfolks-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit George, > 1) 11.2 SDP: B includes --- should be A includes Fixed. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 15 16:23:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10773 for ; Fri, 15 Mar 2002 16:23:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26884 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 16:23:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26373; Fri, 15 Mar 2002 16:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26342 for ; Fri, 15 Mar 2002 16:08:19 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10401 for ; Fri, 15 Mar 2002 16:08:15 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2FL8Ah08300; Fri, 15 Mar 2002 15:08:10 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2FL8AN08274; Fri, 15 Mar 2002 15:08:10 -0600 (CST) Received: from lmf.ericsson.se (rmt160241.am.ericsson.se [138.85.160.241]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA26272; Fri, 15 Mar 2002 15:08:07 -0600 (CST) Message-ID: <3C926342.B7E2D213@lmf.ericsson.se> Date: Fri, 15 Mar 2002 23:10:26 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Dean Willis'" , sip@ietf.org, wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: Re: [Sip] WGLC for Manyfolks draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark, Mark Watson wrote: > > All, > > Two comments: > > 1) Section 11.1 (page 16) describes the sending of a new Offer in the > 200 OK to the INVITE (after an offer/answer exchange has already > completed) in order to take the media off hold: > > "However, if B wants A to generate local ringback, it can put the > media stream on hold in SDP4. In this case, B would put the media > stream off hold by sending an offer in the 200 OK for the INVITE > (8)." > > I thought we decided this was not allowed due to the glare problem (no > way of rejecting the SDP in the 200 OK). Instead the UAS has to send > both an UPDATE and a 200 OK (hopefully at the same time, without > waiting for the response to one before sending the other). Yes, you are right. George had already reported this in a private mail. It is already fixed. Thanks. > > 2) It's not 100% clear which elements are specific to the 'qos' > pre-condition type and which are intended to be general for all > pre-condition types. status-type and strength-type seem to be general > as does direction-tag when applied to the confirmation status (which > direction(s) is confirmation required ?). These things would work in > the same way for any new pre-condition tags as they do for qos. > > However, direction-tag applied to current and desired status seems to > have a specific meaning related to the direction of QoS reservations. > Other pre-condition types could be imagined for which a different type > of status indication was required. So, perhaps they syntax for curr > and des should include a generalised 'status' which in the case of qos > has type direction-tag ? > I believe that these fields are applicable to more types of preconditions. Thus, I would keep them in the framework. New preconditions types can always define new attributes if needed. For example, a new precondition type could say that the segmented status type MUST NOT be used... > It's important because the behaviour on receipt of pre-conditions with > an unknown pre-condition type need not be to always reject (BTW is > this defined ?). No, it is not. Good point. > A UA can deal with pre-conditions which are 'local' > to the other UA even if it does not recognise the pre-condition type - > namely, ask for confirmation and wait until the curr and des status > for match. I would like an answer with a precondition type to mean that the entity generating the answer understands that precondition type. That might be useful if the other end suddently decides to ask for mandatory remote as well. My proposal is that if you receive an offer with a precondition type that you do not understand, you generate an error response. The error response can carry the preconditions types the UA does understand. The a line with the unknown precondition would have an "unknown" tag, rather than a "failure" tag, which would mean that you understand the precondition type but cannot meet it. I can add text about it in section 8. What do you think? Thanks for your comments, Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Mar 15 19:33:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14720 for ; Fri, 15 Mar 2002 19:33:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA07449 for sip-archive@odin.ietf.org; Fri, 15 Mar 2002 19:33:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06635; Fri, 15 Mar 2002 19:20:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06602 for ; Fri, 15 Mar 2002 19:20:39 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14584 for ; Fri, 15 Mar 2002 19:20:32 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 16 Mar 2002 00:20:50 UT Received: from jolaptop ([80.3.216.239]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Sat, 16 Mar 2002 00:23:35 +0000 From: "Jo Hornsby" To: Cc: Subject: RE: [Sip] WGLC for Update draft Date: Sat, 16 Mar 2002 00:26:44 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <00c601c1c880$8aa4a6a0$133fed0c@C1893415A> X-OriginalArrivalTime: 16 Mar 2002 00:23:35.0940 (UTC) FILETIME=[CFED4C40:01C1CC80] Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Okay, so here's my comments. Apologies for any dups. * Section 1; Paragraph 2; Sentence beginning "While this is reasonable": s/where it this/where this/ * Section 3: Would it perhaps be possible to also include 493? Is there a case where a UAC could automatically Do The Right Thing in this case? * Section 4; Paragraph 2: I'm not quite sure what the differentiation is between 2543bis and 100rel, but shouldn't the reference here also be referencing the RFCxxxx? * Section 4; Paragraph 4: I am unsure as to the motivation for this? Wouldn't it just be better to always do 155 because, certainly at least in the first instance, a large number of proxies are going to be UPDATE-ignorant? * Section 4; Paragraph 5: I'm not quite sure what the differentation is between 2543 and sip-events, but shouldn't the reference here also be referencing the RFCyyyy? * Section 5.1; Paragraph 2: I think the "MAY" worries me. Is the expectation that a large number of UAs are going to support this quite quickly? Else this looks like something that could break interoperability with a sledgehammer. Perhaps there should be a note about how this is slightly dangerous, unless the UA has advanced knowledge of the network/ peer UA? * Section 5.2.1; Paragraph 1: See, here I think if we upgraded the "MAY" to a "SHOULD", we could probably knock out the bit about a proxy flicking the Require: update switch on. But, I'm worried I'm missing something blindingly obvious. &:( * Section 5.2.2; Paragraph 2: I was going to suggest using the Reason header here (header inspection I found a little too icky), but then I referred back to Reason:, and now I get the feeling that this change is already in the pipeline. &:) * Section 5.3; Paragraphs 2/3(motivational): Minor point, but 100rel makes the creation of an "early dialog" a MUST. Obviously, this does no harm, but perhaps the redundancy will cause confusion? * Section 5.3; Paragraph 7: s/proxy/UAC/ * Section 5.3; Paragraph 7: Ah. Here's the placeholder for Reason:. Now I'm betting this is a process issue -- there's no way that Reason is going to be ready in time, right? * Section 6.1: I'm a little confused by the placement of this text, especially given the previous paragraph, which says much the same thing? * Section 6.1.1: I'm a little confused by the "In the case of INVITE". Huh? Is it like in the case of a _session_ created by an INVITE? * Section 6.1.1; Paragraph 3: [BTW, vertical whitespace constitutes a paragraph to my warped mind. I apologize if this is just silly.] Isn't this actually a contradiction with 100rel, since that says that an answer must appear in the first reliable provisional response if there was an offer in the INVITE? I realize that the 155 is just a facade, but it probably needs to be called out that this is in fact okay. * Section 6.1.1; Paragraph 8; Sentence beginning "If the UPDATE": Should it be explicitly pointed out that the "reliable provisional response" must have beed PRACKed; and possibly responded to, if the PRACK contained an offer? In fact, there is some horrible potential for out-of-order with 2xx-to-PRACK and UPDATE here. Hmmm.... This may be a tad radical, but couldn't we just rule out sending offers in PRACKs when a dialog is UPDATE-capable? The only downside I can see is extra request/response pairs when a UAC wants to update session parameters at the exact same time a UAS returns a provisional response reliably. This doesn't seem that likely to me beyond the first provisional response in an early dialog; but I have to admit that I'm manyfolks- ignorant, so it might be of utmost importance there. * Section 6.1.1; Last Paragraph: s/Section 4.1/Section 14.1/ * Section 6.2; Paragraph 2: Might be nice to reference Section 12.2 of RFC BBBB here. Just a thought -- it'll doubtless save my sanity later. * Section 6.2; Paragraph 4; Sentence beginning "Once the application": s/response to request/response to the request/ * Section 6.2.1; Paragraph 2; Sentence beginning "The original request": I'd be inclined to append "for example". * Section 6.2.1; Paragraph 2: Is this paving the way for retrying an UPDATE? (For example: challenge to INVITE in 155; UPDATE with credentials; now the UAS realizes that it doesn't grok the media, so 488 in 155.) This probably needs to either be explicitly allowed or otherwise. * Section 7: Personally, I see this as the wrong approach for maintaining backward compatibility. Although the work that the proxy has to do is somewhat trivial, it seems far more likely that a UA is going to support this extension than a proxy. This means that it's not entirely unlikely that UAs will just not use UPDATE because a proxy is forking but not doing the Require. Also, how likely is it that a UA that isn't UPDATE-aware is going to be fly enough to accept resubmitted requests that are virtual merges? Well, I've said my bit. &:) * Table 1/2; "proxy" column: [I'm comparing the same table in bis-09] o Alert-Info/Call-Info: Is there any reason this is "am" here as opposed to "ar" in bis-09? o Contact: 3xx: Should be "d"? o Content-Length: Should be "ar". o Error-Info: Should be "a"? o Organization: Should be "ar". o Priority: through Record-Route:: Need aligning with Table 3 of bis-09. o Require: Not sure what "c" means here. o Route: Should be "adr". o Via:/WWW-Authenticate:: Require alignment with Table 3 of bis-09. * Table 1/2; "UPDATE" column: o Allow: 405: Should be "m"? o Contact: R/2xx: Should be "m"? o Min-Expires: 423: Should be "m"? o Unsupported: 420: Should be "m"? Same issues with aligning with bis-09 Tables in terms of Proxy-Authenticate/ Record-Route/Via/WWW-Authenticate; specifically, the "where" column. * Table 2: "copied with possible addition of tag" I don't think makes sense here, since there's always going to be a tag, right? * Section 12.3: CopyPaste error? (Should be talking about the 155, right?) Finally, is any normative behaviour required for the case when an UPDATE is received after, say, the initial INVITE has completed unsuccessfully? An obvious case where this could happen, that I can think is where a CANCEL has been issued, and theres vague racing going on. I'm guessing you just 487, but perhaps this should be spelled out? (Especially if you don't 487� (:&). And I'm done. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Sat Mar 16 05:07:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01263 for ; Sat, 16 Mar 2002 05:07:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA09479 for sip-archive@odin.ietf.org; Sat, 16 Mar 2002 05:07:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08613; Sat, 16 Mar 2002 04:44:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08585 for ; Sat, 16 Mar 2002 04:44:15 -0500 (EST) Received: from web20205.mail.yahoo.com (web20205.mail.yahoo.com [216.136.226.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01097 for ; Sat, 16 Mar 2002 04:44:11 -0500 (EST) Message-ID: <20020316094414.53388.qmail@web20205.mail.yahoo.com> Received: from [172.129.138.185] by web20205.mail.yahoo.com via HTTP; Sat, 16 Mar 2002 01:44:14 PST Date: Sat, 16 Mar 2002 01:44:14 -0800 (PST) From: Aditi Budhraja To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi I have a couple of questions related to service logic creation and sip extension drafts a) Are there provisions by which the existing SIP stack can be extended to support the extension drafts that IETF comes up with.In other words,are there APIs by which new messages/headers/content types canbe created in existing SIP entities without coming out with a new version of the same.Pls illustrate with an example b) Service logic creation tools such as CPL etc can provide service creation by looking into existing messages etc.What happens when an extension comes up that introduces a new message/header etc that might have to be used to create a new service.Is there a provision to handle this relationship between scripting languages etc and new extensions to the protocol.eg How do I create a new service using instant messaging with CPL which I don't think understands SUBSCRIBE/NOTIFY messages c) Is there any draft for service creation in 3g networks Thanks Aditi __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 16 11:57:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05931 for ; Sat, 16 Mar 2002 11:57:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24249 for sip-archive@odin.ietf.org; Sat, 16 Mar 2002 11:57:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21209; Sat, 16 Mar 2002 10:37:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21181 for ; Sat, 16 Mar 2002 10:37:56 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04938 for ; Sat, 16 Mar 2002 10:37:52 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2GFbqh20667; Sat, 16 Mar 2002 09:37:53 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2GFbqJ01689; Sat, 16 Mar 2002 09:37:52 -0600 (CST) Received: from lmf.ericsson.se (rmt160153.am.ericsson.se [138.85.160.153]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA11385; Sat, 16 Mar 2002 09:37:50 -0600 (CST) Message-ID: <3C936760.E1127C5D@lmf.ericsson.se> Date: Sat, 16 Mar 2002 17:40:16 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: sip@ietf.org, jdrosen@dynamicsoft.com Subject: Re: [Sip] WGLC for Update draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Jo Hornsby wrote: > In fact, there is some horrible potential > for out-of-order with 2xx-to-PRACK and > UPDATE here. Hmmm.... This may be a > tad radical, but couldn't we just rule > out sending offers in PRACKs when a > dialog is UPDATE-capable? The only > downside I can see is extra > request/response pairs when a UAC wants > to update session parameters at the exact > same time a UAS returns a provisional > response reliably. This doesn't seem > that likely to me beyond the first > provisional response in an early dialog; > but I have to admit that I'm manyfolks- > ignorant, so it might be of utmost > importance there. I would like to rule it out as well. The problem here is that offers in PRACKs cannot be refused. Glare is not a problem, because the UAS will not generate an update if it has an unPRACKed 1xx response, but if the offer in the PRACK is not acceptable, the UAS cannot refuse it, because the PRACK has to be answered with a 200 OK anyway. So, either an error response for a PRACK indicating that the session description was not accepted is allowed (the same mechanism that exists for UPDATE) or we rule out offers in PRACK. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 16 15:43:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09139 for ; Sat, 16 Mar 2002 15:42:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04881 for sip-archive@odin.ietf.org; Sat, 16 Mar 2002 15:43:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00030; Sat, 16 Mar 2002 13:55:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29997 for ; Sat, 16 Mar 2002 13:55:06 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07808 for ; Sat, 16 Mar 2002 13:54:34 -0500 (EST) Received: (from sardana@localhost) by obsoft.com (8.11.6/8.11.6) id g2GIxYK25173; Sat, 16 Mar 2002 10:59:34 -0800 Date: Sat, 16 Mar 2002 10:59:34 -0800 From: Bobby Sardana Message-Id: <200203161859.g2GIxYK25173@obsoft.com> To: aditibudhraja@yahoo.com, sip@ietf.org Subject: Re: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline! Aditi Budhraja wrote: >a) Are there provisions by which the existing SIP >stack can be extended to support the extension drafts >that IETF comes up with.In other words,are there APIs >... Please check the following: http://www.cs.columbia.edu/sip There are many SIP stacks available and can be extended to perform what you want. >b) Service logic creation tools such as CPL etc can >provide service creation by looking into existing >messages etc.What happens when an extension comes up >that introduces a new message/header etc that might >have to be used to create a new service.Is there a >provision to handle this relationship between >scripting languages etc and new extensions to the >protocol.eg How do I create a new service using >instant messaging with CPL which I don't think >understands SUBSCRIBE/NOTIFY messages An extensible SCE, that understands CPL, would be required to perform what you want. I am not aware of one in the SIP world. Regards, Bobby Sardana. sardana@obsoft.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 daemon@optimus.ietf.org Sun Mar 17 22:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18737 for ; Sun, 17 Mar 2002 22:43:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25638 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 22:44:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24747; Sun, 17 Mar 2002 22:27:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24713 for ; Sun, 17 Mar 2002 22:27:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17496 for ; Sun, 17 Mar 2002 22:27:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I3S3TE008317; Sun, 17 Mar 2002 22:28:04 -0500 (EST) Message-ID: <3C954139.9FEFC98B@dynamicsoft.com> Date: Sun, 17 Mar 2002 20:22:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: William Marshall , salreyca@teleco.upv.es, sip@ietf.org Subject: Re: [Sip] mayfolks References: <3C923666.22B6656E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hi > > William Marshall wrote: > > > > Salva wrote: > > > is it allowed to send an answer with preconditions to an offer > > > that didn't contain them (not even the none option tag)? > > > > This is the case that led to my suggestion that a MUST be added > > to the last paragraph of section 5.1. If the offerer MUST generate > > the SDP by the rules of 5.1.1 and section 4, then there will be a > > precondition line containing "none" and the answer can upgrade it. > > > > Otherwise, when the offer is made by the UAS, there is no mechanism > > for the UAC to know whether preconditions were supported or not. > > (When the offer is made by the UAC, then the Supported header can > > indicate this, but this doesn't work the other direction). > > Exactly. Besides, the supported header does not tell anything about the > preconditions types (e.g., qos) supported. Lines with none tags do. Whilst I don't disagree that its better to insert preconditions only in the answer if the none precondition was present in the offer, I actually do think Supported ought to be allowed in the 1xx. This is not the case according to table 2, unfortunately, which makes no mention of its presence in anything but 2xx. However, I would think that it is sensible in any response that establishes a dialog, which includes, but is not limited to, 2xx. The same goes for other headers like Accept, Accept-Encoding, Allow, etc. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sun Mar 17 22:43:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18753 for ; Sun, 17 Mar 2002 22:43:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA25652 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 22:44:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24700; Sun, 17 Mar 2002 22:27:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA24675 for ; Sun, 17 Mar 2002 22:27:29 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17494 for ; Sun, 17 Mar 2002 22:27:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I3RuTE008314; Sun, 17 Mar 2002 22:27:56 -0500 (EST) Message-ID: <3C953C33.25BF49F1@dynamicsoft.com> Date: Sun, 17 Mar 2002 20:00:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: William Marshall , sip@ietf.org Subject: Re: [Sip] Re: REFER security References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > On Thu, 14 Mar 2002, William Marshall wrote: > > The issue that I raised with REFER security during its last-call > period > > last year was the inability of the transfer-target to authenticate > > the Referred-By header with the transferor. While there may be > > an authenticated relationship between the transferee and the > transferor > > (established by an INVITE, and used by the REFER), and an > authenticated > > relationship between the transferee and the transfer-target > (established by > > the REFER-initiated INVITE), there is no way for the transfer-target > > (i.e. UAS in the second INVITE) to verify that the transferor really > > did send a REFER to the UAC. > > Then you are discussing the security of cc-transfer, not the security of > REFER. This doesn't mean we don't need a solution, but figuring out how > to trust a header in an INVITE doesn't exactly seem like a job for the > document that defines REFER. Certainly, more things than cc-transfer would benefit from a capability like this. I think the general problem is a mechanism for A to indicate to B a piece of information (a sip fragment or full sip mesage) which is signed by a third party. Such a mechanism is arguably orthogonal to both REFER and cc-transfer. If it existed as a standalone specification, it would probably be handled as a MAY kind of reference in REFER, with more details provided in the cc-transfer spec. One way to accomplish it is with S/MIME. A request can contain fragments with third party signatures. In fact, S/MIME with self-signed certs works REALLY well for cc-transfer. Consider the scenario where A calls B. A provides a self-signed cert in the INVITE, as does B in the 200 OK. Now, they are in a call. A sends a REFER to C. This REFER has a BIG Refer-To URI for B that contains, as a URI parameter, an SMIME body that is a signature over the To, From, Call-ID of the dialog between A and B. In the triggered INVITE from C, this signed body is included. When B receives the triggetred INVITE, it accepts it (remember, it has a Replaces header) only if its signed with the same key provided by A for that dialog. The benefit of this approach is that it doesn't require any pre-shared secrets, no PKI, and allows for excellent assurance that the dialog is being replaced by a triggered REFER from the peer in the dialog. More details needed, but thats the general idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sun Mar 17 23:10:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19125 for ; Sun, 17 Mar 2002 23:10:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA26844 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 23:10:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25987; Sun, 17 Mar 2002 22:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25957 for ; Sun, 17 Mar 2002 22:57:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18972 for ; Sun, 17 Mar 2002 22:57:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I3w8TE008331; Sun, 17 Mar 2002 22:58:08 -0500 (EST) Message-ID: <3C956590.8267E758@dynamicsoft.com> Date: Sun, 17 Mar 2002 22:57:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] 200 UPDATE race condition References: <3C89CD3F.4D1EA6DA@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > Another race condition... > > Assume UA_B sends a 200 to an INVITE, without SDP (it has been sent > earlier in a reliable 18x). > > Then it receives an UPDATE, with a new offer. > > Now, there are two possible scenarios: > > 1. UA_A (the caller) receives the 200 for the INVITE, sends ACK, and > then sends UPDATE, but for whatever reason the UPDATE reaches UA_B > before the ACK. > > 2. UA_A sends the UPDATE at the same time as UA_B sends the 200 for the > INVITE, ie we have a race condition. Why? There is no SDP in the 2xx to the INVITE, or in the ACK. Thus, the relative ordering of the 2xx and the UPDATE are irrelevant. There is no race condition. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sun Mar 17 23:18:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19231 for ; Sun, 17 Mar 2002 23:18:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA27087 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 23:18:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26644; Sun, 17 Mar 2002 23:04:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA26612 for ; Sun, 17 Mar 2002 23:04:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19067 for ; Sun, 17 Mar 2002 23:04:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I451TE008334; Sun, 17 Mar 2002 23:05:01 -0500 (EST) Message-ID: <3C95672D.E4626303@dynamicsoft.com> Date: Sun, 17 Mar 2002 23:03:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org, gonzalo.camarillo@lmf.ericsson.se Subject: Re: [Sip] PRACK question: draft-ietf-sip-100rel-06 References: <3C8473FF.B50CEE6E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > Thanks for your answers! > > I know that we can't have two "active" offers. My point was that if it > should be mentioned also in chapter 5 of the 100rel draft, but I guess > it's > not necessary. > > Another question: > > UA_A sends an INVITE, with SDP (offer 1). > > UA_B sends back the first 18x provisional response, WITH SDP (answer 1). > > UA_A sends the first PRACK, WITHOUT SDP. > > UA_B sends back the second 18x provisional response, WITHOUT SDP. > > UA_A sends the second PRACK, WITH SDP (offer 2). This is illegal. According to 100rel: If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK. Generating additional offers in the PRACK is contingent on receiving an answer in the 1xx. The result is that there will only ever be one generating of an offer in PRACK, since only the first reliable provisional response can have an answer. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sun Mar 17 23:44:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19866 for ; Sun, 17 Mar 2002 23:44:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA28451 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 23:44:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27249; Sun, 17 Mar 2002 23:23:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA27215 for ; Sun, 17 Mar 2002 23:23:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19286 for ; Sun, 17 Mar 2002 23:23:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I4NxTE008374; Sun, 17 Mar 2002 23:23:59 -0500 (EST) Message-ID: <3C956B9F.D73BC00@dynamicsoft.com> Date: Sun, 17 Mar 2002 23:22:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Glare with PRACK vs. UPDATE. Was: Question on manyfolks 05 References: <200203071437.JAA69344@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Krisztian Kiss wrote: > > I guess Xin's original question concerned the case when the initial > INVITE > > contains an offer + Require:precondition. When sending the PRACK, the > > precondition has not been met yet, so the question is whether it is > allowed > > to send a new offer in PRACK with Require:precondition. > > I believe this is allowed in the current offer/answe description. > The original offer, in the INVITE, was answered in the provisional > response. So at that point there is no offer pending, and either > endpoint can send a new offer. The UAC can include the new offer > in the PRACK message. > > However, this is an issue of glare here. Since there is no > offer pending, the UAS can also send an updated offer in an > UPDATE message. While UPDATE vs. UPDATE glare needs to be > covered in the update draft, there is also a possibility of > PRACK vs. UPDATE glare. In that case, I believe UPDATE > should yield to PRACK in order to make the 100rel work. > Can this case also be covered in the discussion of glare > in the next revision of draft-ietf-sip-ipdate? There are really two fixes to this problem. The first fix, is to codify what has already been suggested by Gonzalo within this thread: > A PRACK for a 1xx response that contained an answer can contain an offer > (as stated in the draft), because the UAS will not generate an UPDATE > until it receives the PRACK... therefore, in that situation, there is > not a chance of having a glare condition... it is OK as it is specified. If the UAS can't send an UPDATE till it gets the PRACK for a 18x that contained an answer, we will have no PRACK/UPDATE glare. The second approach was suggested by Bill: > t seems to me that a perfectly valid sequence is > --- INVITE (offer) ---> > <-- 183 (answer) ------ > --- PRACK (offer) \ > <-- UPDATE (offer) ---- > \-- > and at this point there is glare. > > The 100rel draft now requires the UAS to respond to the offer in the > PRACK with an answer in the 200 (OK). > > The nearest text which is close to this case is update-01 section 6.2.1 > If an UPDATE is received that contains an offer, and the UAS has > generated an offer (presumably in an UPDATE of its own) to which it > has not yet received an answer, the UAS MUST reject the UPDATE with a > 491 response. > > This text in 6.2.1 should be generalized to cover this additional glare > case, by requiring the UAC to respond to an UPDATE request with a 491 > if it has an outstanding offer pending in a PRACK. I'd suggest: > If an UPDATE is received that contains an offer, and the receiver has > generated an offer to which it has not yet received an answer, the > UPDATE MUST be rejected with a 491 response. > If you also specify that a PRACK needs to be rejected if you have sent an UPDATE to which you didn't get an answer, yes, this will work. Rejecting PRACK is generally a bad thing. You can't specify that "UPDATE wins", since that would require both participants to recognize there is glare, and this is not possible. So, to avoid rejection of PRACK, I'd prefer the first option, to add the text suggested by Gonzalo. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Sun Mar 17 23:49:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20077 for ; Sun, 17 Mar 2002 23:49:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA28709 for sip-archive@odin.ietf.org; Sun, 17 Mar 2002 23:49:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28184; Sun, 17 Mar 2002 23:35:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28085 for ; Sun, 17 Mar 2002 23:35:26 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19499 for ; Sun, 17 Mar 2002 23:30:49 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2I4VPTE008380; Sun, 17 Mar 2002 23:31:25 -0500 (EST) Message-ID: <3C956D5D.A1B57706@dynamicsoft.com> Date: Sun, 17 Mar 2002 23:30:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 References: <200203122239.RAA02897@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Gonzalo wrote: > > A PRACK for a 1xx response that contained an answer can contain an > offer > > (as stated in the draft), because the UAS will not generate an UPDATE > > until it receives the PRACK... therefore, in that situation, there is > > not a chance of having a glare condition... it is OK as it is > specified. > > I'm still a little confused about this. I don't see where the > restriction > is written that the UAS MUST NOT generate a new offer until its answer > is acknowledged -- only that it send the answer before a new offer. Right, this is not written at this time, although I believe it should be. > > There are four separate drafts that interact in making the rules: > > in offer-answer-02, section 8 > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session. ... > in 2543bis-09, section 13.2.1 > If the initial offer is in an INVITE, the answer MUST be in a reliable > non-failure message from UAS back to UAC which is correlated to that > INVITE. ... > in 100rel-06, section 5 > If the INVITE contained an offer, the UAS MAY generate an answer in a > reliable provisional response. ... If the UAC receives a reliable > provisional response with an answer, it MAY generate an additional > offer in the PRACK. If the UAS receives a PRACK with an offer, it > MUST place the answer in the 2xx to the PRACK. > in update-01, section 6.1.1 > ... for the callee: If the UPDATE is being sent before the completion > of the INVITE transaction, and the initial INVITE contained an offer, > the UPDATE annot be sent unless the callee has generated an answer > in a reliable provisional response, and has not sent or received > other UPDATE requests containing offers that have not been answered. > > It seems to me that a perfectly valid sequence is > --- INVITE (offer) ---> > <-- 183 (answer) ------ > --- PRACK (offer) \ > <-- UPDATE (offer) ---- > \-- > and at this point there is glare. Correct. > > The 100rel draft now requires the UAS to respond to the offer in the > PRACK with an answer in the 200 (OK). > > The nearest text which is close to this case is update-01 section 6.2.1 > If an UPDATE is received that contains an offer, and the UAS has > generated an offer (presumably in an UPDATE of its own) to which it > has not yet received an answer, the UAS MUST reject the UPDATE with a > 491 response. > > This text in 6.2.1 should be generalized to cover this additional glare > case, by requiring the UAC to respond to an UPDATE request with a 491 > if it has an outstanding offer pending in a PRACK. I'd suggest: > If an UPDATE is received that contains an offer, and the receiver has > generated an offer to which it has not yet received an answer, the > UPDATE MUST be rejected with a 491 response. You might still end up rejecting PRACK, which you'd generally prefer to avoid. My proposal is to incorporate Gonzalos suggestion. > An editorial nit in update-01, section 6.1.1 final paragraph should > reference section 14.1 of RFC BBBB, not section 4.1. Fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 18 01:23:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21268 for ; Mon, 18 Mar 2002 01:23:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA13231 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 01:23:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01390; Mon, 18 Mar 2002 00:46:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01345 for ; Mon, 18 Mar 2002 00:46:00 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20702 for ; Mon, 18 Mar 2002 00:45:57 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id ED8C51E040; Mon, 18 Mar 2002 00:45:54 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA21468; Mon, 18 Mar 2002 00:45:51 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id AAA21400; Mon, 18 Mar 2002 00:44:30 -0500 (EST) Date: Mon, 18 Mar 2002 00:44:30 -0500 (EST) Message-Id: <200203180544.AAA21400@fish.research.att.com> To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote, in part: > You might still end up rejecting PRACK, which you'd generally prefer to > avoid. My proposal is to incorporate Gonzalos suggestion. Could I ask you to be a little more clear on the exact proposed change here. I think I've heard two suggestions in Gonzalo's emails: 1) that the UAS be prohibited from sending an UPDATE until it has received the PRACK from a 1xx containing an answer 2) that PRACK never contain an offer SDP (or was it any SDP?) Point #1 is difficult, since answers contained in 200(Ok) to UPDATE are not positively acknowledged. I believe the following two cases should be considered identical: --INVITE (offer)---> --UPDATE (offer)---> X-183 (answer)--- X-200 (answer)--- <--UPDATE (offer)--- <--UPDATE (offer)--- -----491-----------> -----491-----------> Thus there will always be the case (lost 200 to UPDATE) where one side thinks an offer is pending and the other thinks it has been answered. Error 491 will resolve it. Forcing the UAS to wait for the PRACK solves one but not the other. While prohibiting an offer in a PRACK will work (but is an efficiency tradeoff), we need to allow an answer to be in the PRACK when the offer is contained in a 1xx reliable provisional response. Otherwise we have UPDATEs with answers, and that is a mess. As for the efficiency argument -- could someone from 3GPP state whether offers are currently sent in PRACKs? If so, is it a problem to change? Bill Marshall wtm@research.att.com -----original message----- Date: Sun, 17 Mar 2002 23:30:21 -0500 From: Jonathan Rosenberg To: William Marshall Cc: sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 William Marshall wrote: > > Gonzalo wrote: > > A PRACK for a 1xx response that contained an answer can contain an > offer > > (as stated in the draft), because the UAS will not generate an UPDATE > > until it receives the PRACK... therefore, in that situation, there is > > not a chance of having a glare condition... it is OK as it is > specified. > > I'm still a little confused about this. I don't see where the > restriction > is written that the UAS MUST NOT generate a new offer until its answer > is acknowledged -- only that it send the answer before a new offer. Right, this is not written at this time, although I believe it should be. > > There are four separate drafts that interact in making the rules: > > in offer-answer-02, section 8 > At any point during the session, either participant MAY issue a new > offer to modify characteristics of the session. ... > in 2543bis-09, section 13.2.1 > If the initial offer is in an INVITE, the answer MUST be in a reliable > non-failure message from UAS back to UAC which is correlated to that > INVITE. ... > in 100rel-06, section 5 > If the INVITE contained an offer, the UAS MAY generate an answer in a > reliable provisional response. ... If the UAC receives a reliable > provisional response with an answer, it MAY generate an additional > offer in the PRACK. If the UAS receives a PRACK with an offer, it > MUST place the answer in the 2xx to the PRACK. > in update-01, section 6.1.1 > ... for the callee: If the UPDATE is being sent before the completion > of the INVITE transaction, and the initial INVITE contained an offer, > the UPDATE annot be sent unless the callee has generated an answer > in a reliable provisional response, and has not sent or received > other UPDATE requests containing offers that have not been answered. > > It seems to me that a perfectly valid sequence is > --- INVITE (offer) ---> > <-- 183 (answer) ------ > --- PRACK (offer) \ > <-- UPDATE (offer) ---- > \-- > and at this point there is glare. Correct. > > The 100rel draft now requires the UAS to respond to the offer in the > PRACK with an answer in the 200 (OK). > > The nearest text which is close to this case is update-01 section 6.2.1 > If an UPDATE is received that contains an offer, and the UAS has > generated an offer (presumably in an UPDATE of its own) to which it > has not yet received an answer, the UAS MUST reject the UPDATE with a > 491 response. > > This text in 6.2.1 should be generalized to cover this additional glare > case, by requiring the UAC to respond to an UPDATE request with a 491 > if it has an outstanding offer pending in a PRACK. I'd suggest: > If an UPDATE is received that contains an offer, and the receiver has > generated an offer to which it has not yet received an answer, the > UPDATE MUST be rejected with a 491 response. You might still end up rejecting PRACK, which you'd generally prefer to avoid. My proposal is to incorporate Gonzalos suggestion. > An editorial nit in update-01, section 6.1.1 final paragraph should > reference section 14.1 of RFC BBBB, not section 4.1. Fixed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 18 03:41:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00957 for ; Mon, 18 Mar 2002 03:41:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19324 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 03:41:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17956; Mon, 18 Mar 2002 03:15:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17928 for ; Mon, 18 Mar 2002 03:15:29 -0500 (EST) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00619; Mon, 18 Mar 2002 03:15:15 -0500 (EST) From: mkramanna@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hss.hns.com (8.11.2/8.11.2) with SMTP id g2I7qEO03293; Mon, 18 Mar 2002 13:22:17 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B80.002C6291 ; Mon, 18 Mar 2002 13:34:48 +0530 X-Lotus-FromDomain: HSSBLR To: Internet-Drafts@ietf.org cc: sip@ietf.org Message-ID: <65256B80.002C628C.00@sampark.hss.hns.com> Date: Mon, 18 Mar 2002 13:42:55 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Comments on SIP-URL grammar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, In the draft it is said that the password field of userinfo can have zero characters. If the user specifies ":" after the user field, why is it that zero characters are allowed for the password field. Shouldn't it be one or more characters? Similarly shouldn't it be one or more characters for the userfield also. SIP-URL = "sip:" [ userinfo "@" ] hostport url-parameters [ headers ] userinfo = [ user | telephone-subscriber [ ":" password ]] user = *( unreserved | escaped | user-unreserved ) password = *( unreserved | escaped | " " | "=" | "+" | "$" | "," ) According to the grammar the following examples are valid. sip:user:@myserver.com sip::password@myserver.com regards, mohan This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 18 05:52:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02768 for ; Mon, 18 Mar 2002 05:52:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25708 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 05:52:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24561; Mon, 18 Mar 2002 05:26:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA24534 for ; Mon, 18 Mar 2002 05:26:43 -0500 (EST) Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02464 for ; Mon, 18 Mar 2002 05:26:37 -0500 (EST) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Mon, 18 Mar 2002 11:38:07 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [Sip] SDP in unreliable 18x Reply-to: salreyca@teleco.upv.es Message-ID: <3C95D19F.18566.5BD15C@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) X-SMTP-Server: PostCast Server 1.0.0 Content-Transfer-Encoding: 7BIT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, see at end (again) On 15 Mar 2002, at 19:53, Gonzalo Camarillo wrote: > Hi, > > Salva Rey Calatayud wrote: > > > > Hi, > > > > please see inline at end, > > > > On 7 Mar 2002, at 22:01, Jonathan Rosenberg wrote: > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > Hi Bob, > > > > > > > > > >Now, does this mean I'm not allowed to send an SDP in an UN-reliable > > > > > >18x? And, if I do, is it then not regardes as an answer? > > > > > > > > > > You are allowed to send SDP in an unreliable 1xx. However, it MUST be > > > > the > > > > > same as the SDP you will send in a 2xx. The key sentence is "That same > > > > exact > > > > > answer MAY also be placed in any provisional responses sent prior to > > > > the > > > > > answer." > > > > > > > > True. But, in this case the UAC is not allowed to send a new offer (eg > > > > using > > > > UPDATE) before it has received the final response. > > > > > > Right. The idea was to try and add a semblance of compatibility with > > > existing implementations. We want everything to be mapped to a set of > > > non-overlapping O/A exchanges. So, the idea is that the SDP in an > > > unrealiable 18x, and the SDP in a 2xx, are just the same answer. THus, > > > we maintain the property of everything being a series of O/A exchanges, > > > but allow a single answer to be present in multiple sip responses. > > > > > > However, it is NOT allowed, to send an offer in INVITE, an answer in a > > > reliable 183, and then repeat the answer in the next reliable 183. Thats > > > because the answer has to be in the first reliable response sent back, > > > which is the first 183. The SDP in the second 183 would be illegal, > > > since it would be an offer, and those can't go in responses after the > > > first SDP. > > > > I don't quite understand why these new offer on th > > e reliable 183 > > would be illegal. Isn't it conveyed on a reliable delivered message. I > > thought that was the only condition for O/A exchanges. or is it that > > it's only allowed one O/A exchange per transaction? > > > > It is illegal to avoid glare conditions, where you could not refuse the > offer in the provisional response even though you would have sent an > UPDATE. > > The update draft outlines when you can send an offer and how. I never mentioned the UPDATE method being used here. could you answer my question why a second 183 rel conveying a second offer is illegal? feel free to give references to sections in drafts. In a couple of my questions you always refer me to the update draft and suggested that I should read it. What does it make you think I haven't? If everything was so clear in the drafts we wouldn't be needing at all this mailing lists. I am afraid that drafts are far from error-free documents. So, be gentler and try to give an answer to questions instead of making references to documents all the time. And one second question on this email : How many lines in the update draft mention that a UAS can issue an UPDATE? thanks and regards, Salva ********************************** Salvador Rey Calatayud, M.Sc. Siemens AG Room 53521 salreyca@teleco.upv.es Munich, Perlach Phone number : +49-16095178051 ********************************** _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 18 06:12:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03072 for ; Mon, 18 Mar 2002 06:12:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA26623 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 06:12:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25696; Mon, 18 Mar 2002 05:51:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25666 for ; Mon, 18 Mar 2002 05:51:55 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02763 for ; Mon, 18 Mar 2002 05:51:50 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2IAoYN00095; Mon, 18 Mar 2002 11:50:35 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2IAnsa00492; Mon, 18 Mar 2002 10:49:54 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 10:50:37 -0000 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo'" Cc: "'Dean Willis'" , sip@ietf.org, wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: RE: [Sip] WGLC for Manyfolks draft Date: Mon, 18 Mar 2002 10:50:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CE6A.BA1F8E50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CE6A.BA1F8E50 Content-Type: text/plain > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 15 March 2002 21:10 > > However, direction-tag applied to current and desired > status seems to > > have a specific meaning related to the direction of QoS > reservations. > > Other pre-condition types could be imagined for which a > different type > > of status indication was required. So, perhaps they syntax for curr > > and des should include a generalised 'status' which in the > case of qos > > has type direction-tag ? > > > > I believe that these fields are applicable to more types of > preconditions. Thus, I would keep them in the framework. New > preconditions types can always define new attributes if needed. For > example, a new precondition type could say that the segmented status > type MUST NOT be used... > OK, if I think hard, I can pursuade myself that the concept of 'direction-tag' is relevant to all future pre-condition types, in that it makes sense to say 'This precondition must be met to enable the send/recv/both media streams to start' (If the precondition is not needed for either of the directions, then it is not really a precondition!). > I would like an answer with a precondition type to mean that > the entity > generating the answer understands that precondition type. > That might be > useful if the other end suddently decides to ask for > mandatory remote as > well. > > My proposal is that if you receive an offer with a precondition type > that you do not understand, you generate an error response. The error > response can carry the preconditions types the UA does understand. > > The a line with the unknown precondition would have an "unknown" tag, > rather than a "failure" tag, which would mean that you understand the > precondition type but cannot meet it. > > I can add text about it in section 8. What do you think? I still think there is no reason in principle why a UA needs to understand the pre-condition type in order to be able to deal with the other end requiring local pre-conditions. If I get: A-->B a=des: foo mandatory local sendrecv I can reply with: B-->A a=des: foo mandatory remote sendrecv a=conf: foo remote recv Which (if I've got my directions right) just means that I would like to receive confirmation when the A's foo conditions have been met. If I later get: A-->B a=des: foo mandatory remote sendrecv I just send B-->A a=des: foo unknown remote sendrecv or whatever. Does it matter that A does not know that B does not recognise foo until A tries to require a mandatory foo condition on B ? It will be frustrating if we discover a kind of pre-condition in future which (for example) is only relevant at the UAC, but we find that we cannot make it work with UASs which do not understand the new pre-condition tag. i.e. there is no need to upgrade the UAS to functionally make the pre-condition work, but we've imposed an artificial requirement to upgrade the UAS because of the way we designed the protocol. As a general point, the scope says this is a 'general framework for preconditions' but the text often implies that the pre-conditions are related to 'network resources'. Just 'resources' would be better, as there may be pre-conditions which are not related to the network, but to resources at the UAS/UAC. And a final language thing. In the definition of the Desired status, and elsewhere, we refer to the 'value' of the current and desired status attributes, but we do not define exactly what this means - it is obviously not the whole of the attribute, because their syntax is different. Instead of 'When the current status value has the same or a better value than the desired status value, the preconditions are considered to be met for each stream.', I think what is meant is: 'When the direction-tag of the current status attribute with a given precondition-type/status-type is equal to (or better than) the direction-tag of the desired status attibute with the same precondition-type/status-type, then the preconditions are considered to be met.' Regards...Mark ------_=_NextPart_001_01C1CE6A.BA1F8E50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] WGLC for Manyfolks draft

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 15 March 2002 21:10
<snip>

> > However, direction-tag applied to current = and desired
> status seems to
> > have a specific meaning related to the = direction of QoS
> reservations.
> > Other pre-condition types could be = imagined for which a
> different type
> > of status indication was required. So, = perhaps they syntax for curr
> > and des should include a generalised = 'status' which in the
> case of qos
> > has type direction-tag ?
> >
>
> I believe that these fields are applicable to = more types of
> preconditions. Thus, I would keep them in the = framework. New
> preconditions types can always define new = attributes if needed. For
> example, a new precondition type could say that = the segmented status
> type MUST NOT be used...
>

OK, if I think hard, I can pursuade myself that the = concept of 'direction-tag' is relevant to all future pre-condition = types, in that it makes sense to say 'This precondition must be met to = enable the send/recv/both media streams to start' (If the precondition = is not needed for either of the directions, then it is not really a = precondition!).

<snip>

> I would like an answer with a precondition type = to mean that
> the entity
> generating the answer understands that = precondition type.
> That might be
> useful if the other end suddently decides to = ask for
> mandatory remote as
> well.
>
> My proposal is that if you receive an offer = with a precondition type
> that you do not understand, you generate an = error response. The error
> response can carry the preconditions types the = UA does understand.
>
> The a line with the unknown precondition would = have an "unknown" tag,
> rather than a "failure" tag, which = would mean that you understand the
> precondition type but cannot meet it.
>
> I can add text about it in section 8. What do = you think?

I still think there is no reason in principle why a = UA needs to understand the pre-condition type in order to be able to = deal with the other end requiring local pre-conditions.

If I get:

A-->B
   a=3Ddes: foo mandatory local = sendrecv

I can reply with:

B-->A
  a=3Ddes: foo mandatory remote sendrecv
  a=3Dconf: foo remote recv

Which (if I've got my directions right) just means = that I would like to receive confirmation when the A's foo conditions = have been met.

If I later get:

A-->B
  a=3Ddes: foo mandatory remote sendrecv

I just send

B-->A
  a=3Ddes: foo unknown remote sendrecv

or whatever. Does it matter that A does not know that = B does not recognise foo until A tries to require a mandatory foo = condition on B ?

It will be frustrating if we discover a kind of = pre-condition in future which (for example) is only relevant at the = UAC, but we find that we cannot make it work with UASs which do not = understand the new pre-condition tag. i.e. there is no need to upgrade = the UAS to functionally make the pre-condition work, but we've imposed = an artificial requirement to upgrade the UAS because of the way we = designed the protocol.

As a general point, the scope says this is a 'general = framework for preconditions' but the text often implies that the = pre-conditions are related to 'network resources'. Just 'resources' = would be better, as there may be pre-conditions which are not related = to the network, but to resources at the UAS/UAC.

And a final language thing. In the definition of the = Desired status, and elsewhere, we refer to the 'value' of the current = and desired status attributes, but we do not define exactly what this = means - it is obviously not the whole of the attribute, because their = syntax is different.

Instead of 'When the current status value has the = same or a better value than the desired status value, the preconditions = are considered to be met for each stream.', I think what is meant = is:

'When the direction-tag of the current status = attribute with a given precondition-type/status-type is equal to (or = better than) the direction-tag of the desired status attibute with the = same precondition-type/status-type, then the preconditions are = considered to be met.'

Regards...Mark

------_=_NextPart_001_01C1CE6A.BA1F8E50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 18 06:49:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03462 for ; Mon, 18 Mar 2002 06:49:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28020 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 06:49:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26974; Mon, 18 Mar 2002 06:28:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26943 for ; Mon, 18 Mar 2002 06:28:00 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03211 for ; Mon, 18 Mar 2002 06:27:54 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2IBRXUw018690; Mon, 18 Mar 2002 12:27:34 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id MAA20659; Mon, 18 Mar 2002 12:27:26 +0100 Message-ID: <3C95CF36.69215F7A@lmf.ericsson.se> Date: Mon, 18 Mar 2002 13:27:50 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] 200 UPDATE race condition References: <3C89CD3F.4D1EA6DA@lmf.ericsson.se> <3C956590.8267E758@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Jonathan Rosenberg wrote: > Christer Holmberg wrote: > > > > Hi, > > > > Another race condition... > > > > Assume UA_B sends a 200 to an INVITE, without SDP (it has been sent > > earlier in a reliable 18x). > > > > Then it receives an UPDATE, with a new offer. > > > > Now, there are two possible scenarios: > > > > 1. UA_A (the caller) receives the 200 for the INVITE, sends ACK, and > > then sends UPDATE, but for whatever reason the UPDATE reaches UA_B > > before the ACK. > > > > 2. UA_A sends the UPDATE at the same time as UA_B sends the 200 for the > > INVITE, ie we have a race condition. > > Why? There is no SDP in the 2xx to the INVITE, or in the ACK. Thus, the > relative ordering of the 2xx and the UPDATE are irrelevant. There is no > race condition. That is true for SDP, but let's assume it's a general message body (even if the offer/answer rules don't allow us to include an SDP in the 2xx, I assume we can include other kind of message bodies - ISUP MIMEs, for example...), then, where the CONTENT of the message body in the UPDATE would be different if generated before or after the 2xx. Yes, UA_A may always generate a new UPDATE when it has received the 2xx, but the first UPDATE may already have caused some "damage". Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 18 11:56:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10848 for ; Mon, 18 Mar 2002 11:56:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA16020 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 11:56:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13161; Mon, 18 Mar 2002 11:19:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13133 for ; Mon, 18 Mar 2002 11:18:56 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08880 for ; Mon, 18 Mar 2002 11:18:52 -0500 (EST) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2IGIMd25721; Mon, 18 Mar 2002 08:18:22 -0800 (PST) Received: from ARUNVENKW2Kl (arunvenk-w2kl-2.cisco.com [64.101.164.65]) by sponge.cisco.com (Mirapoint) with SMTP id AAP63710; Mon, 18 Mar 2002 10:18:18 -0600 (CST) From: "Arunachalam Venkatraman" To: "Jonathan Rosenberg" , "Rohan Mahy" Cc: "William Marshall" , Subject: RE: [Sip] Re: REFER security Date: Mon, 18 Mar 2002 10:18:18 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3C953C33.25BF49F1@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Is it possible for a sniffer to use the INVITE/200 exchange between A & B to construct such a INVITE to B that replaces the call from A to B? Since there are no pre-shared secrets, this appears to be a possibility. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: Sunday, March 17, 2002 7:01 PM To: Rohan Mahy Cc: William Marshall; sip@ietf.org Subject: Re: [Sip] Re: REFER security Rohan Mahy wrote: > > On Thu, 14 Mar 2002, William Marshall wrote: > > The issue that I raised with REFER security during its last-call > period > > last year was the inability of the transfer-target to authenticate > > the Referred-By header with the transferor. While there may be > > an authenticated relationship between the transferee and the > transferor > > (established by an INVITE, and used by the REFER), and an > authenticated > > relationship between the transferee and the transfer-target > (established by > > the REFER-initiated INVITE), there is no way for the transfer-target > > (i.e. UAS in the second INVITE) to verify that the transferor really > > did send a REFER to the UAC. > > Then you are discussing the security of cc-transfer, not the security of > REFER. This doesn't mean we don't need a solution, but figuring out how > to trust a header in an INVITE doesn't exactly seem like a job for the > document that defines REFER. Certainly, more things than cc-transfer would benefit from a capability like this. I think the general problem is a mechanism for A to indicate to B a piece of information (a sip fragment or full sip mesage) which is signed by a third party. Such a mechanism is arguably orthogonal to both REFER and cc-transfer. If it existed as a standalone specification, it would probably be handled as a MAY kind of reference in REFER, with more details provided in the cc-transfer spec. One way to accomplish it is with S/MIME. A request can contain fragments with third party signatures. In fact, S/MIME with self-signed certs works REALLY well for cc-transfer. Consider the scenario where A calls B. A provides a self-signed cert in the INVITE, as does B in the 200 OK. Now, they are in a call. A sends a REFER to C. This REFER has a BIG Refer-To URI for B that contains, as a URI parameter, an SMIME body that is a signature over the To, From, Call-ID of the dialog between A and B. In the triggered INVITE from C, this signed body is included. When B receives the triggetred INVITE, it accepts it (remember, it has a Replaces header) only if its signed with the same key provided by A for that dialog. The benefit of this approach is that it doesn't require any pre-shared secrets, no PKI, and allows for excellent assurance that the dialog is being replaced by a triggered REFER from the peer in the dialog. More details needed, but thats the general idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Mon Mar 18 12:35:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12742 for ; Mon, 18 Mar 2002 12:35:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21086 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 12:35:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18655; Mon, 18 Mar 2002 12:10:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18613 for ; Mon, 18 Mar 2002 12:10:53 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11785 for ; Mon, 18 Mar 2002 12:10:48 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2IHA8808334 for ; Mon, 18 Mar 2002 12:10:22 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 11:10:03 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870176@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Mon, 18 Mar 2002 11:03:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] comments on privacy-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Since we now have a WGLC on sip-privacy-04, I have a couple of comments that I apologize in advance for not presenting earlier. I think that SIP needs a network-provided privacy mechanism, and I think the system described by this draft is a reasonable solution to that problem. However, the sip-privacy-04 system is more complicated than it needs to be in order to solve this problem, and these complexities give rise to confusions about the implementation and applicability of the mechanism. Today, the SIP charter speaks to a need for privacy mechanisms but not, for example, for new identity-assertion mechanisms. Jon Peterson NeuStar, Inc. ----- - rpi-screen: As the recent thread in the SIP ML suggested, the behavior in sip-privacy-04 for handling RPIDs received from an untrusted source might be confusing. If untrusted entities shouldn't add the RPID header (which I gather from the applicability), then why not say that a proxy MUST remove any RPID headers it receives from an untrusted source? Today, it sets the 'screen=no' parameter instead. However, no behavior in the document is defined for using an RPID header with 'screen=no' - it merely says that a UA that receives it in a message shouldn't trust it (although what exact behavior this entails is unclear). If this is totally deadweight in signaling, it should just be removed - SIP messages don't need any help getting larger. If you receive a RPID from a trusted entity, 'screen=yes' could just be assumed; a parameter that says "trust me" may very well be redundant in a trusted network. If it turns out that an RPID that the proxy will add itself is identical to an RPID that has been supplied by an untrusted source, then while this may be just lip service I think the least ambiguous and most secure language is still to say that the proxy removes the untrusted header and adds a trusted header. If for whatever reason it turns out we do need this parameter, the idea that both 'screen=yes' and 'screen=no' can appear in the same RPID header (this is permitted in 6.1) must be unnecessary. Finally, if you are going to have this parameter, calling it "screen" is a little misleading; screening in the PSTN can refer to selectively blocking calls based on the original calling/called number (to me it implies that some feature has been invoked that inspects the ANI and the dialed number and determines that this is a legitimate target for the caller's class of service). Maybe "verify" would make more sense. - rpi-pty-type: This parameter allows you to specify which party's identity is contained in the RPID header ("calling" or "called" are currently allowed). However, no motivation for this capability is presented in the draft - it defines the conditions under which these parameters are inserted, but there is no recipient behavior that justifies their insertion. Moreover, the behavior for adding the parameter holds only that a request contains a 'calling' id, and the response contains a 'called' id. This sounds right - I'd imagine that a privacy mechanism would use the RPID header to express the private identity of the sender of a message; and in fact, if the rpi-id-type header is not present, that's exactly what the recipient assumes. So in short the motivation for this parameter isn't clear. If there is a need for it then the draft should describe it, otherwise, I think this parameter should be removed, since the default behavior seems appropriate. This draft allows network-asserted identity as a means to end-user privacy; the identity that is private is the identity of the originator of the message. Finally, if you are going to have this parameter anyway, "calling" and "called" are a little too telephony-specific, and those telephony roles don't map cleanly onto the mechanism. This is already causing problems in the draft: in 7.5, it suggests that you proxies should use the "calling" rpi-id-type to identify the originator of any INVITE request - but what about a re-INVITE in the reverse direction in the middle of a dialog? - rpi-id-type: I find this the most problematic of the existing parameters. I believe that the sip-privacy mechanism (at least, this chartered work) exists to make an identity private, not to invent new forms of identity. I believe that the kinds of entities in a SIP network that have privacy concerns are users - not client devices, or intermediary devices, or what have you. Now, that isn't to say that keeping a user's identity private might not require hiding information about the device from which a user is calling, and so on. This does not, however, motivate a need for a network-asserted device URI like the "term" value of the rpi-id-type. No proxy or UAS behavior is suggested in the document for use of the "term" rpi-id-type, nor is it made clear how a proxy inserting this RPID would know to assert an "identity" for a terminal (possibly from some out-of-band authentication mechanism? but does the terminal authenticate itself as well as the user?). Also, the distinction between "user" and "subscriber" in privacy-04 is a little confusing. They represent a new distinction between identities in SIP, and it isn't particularly clear why they are required as part of a privacy mechanism; the difference between a "subscriber" (the default, and traditionally the user of the SIP session), and a "user" seems to be somehow related to settlement, or the administrative grouping of user accounts. It isn't clear how a proxy would ascertain that it needs to apply these parameters to an RPID, or how they'd be used So, I'd also like to suggest that if there is a need for a parameter or header that can assert arbitrary new types of identity (distinguishing between subscribers or users, URIs for devices, secret superhero identities, etc), then I for one would like to see this proposed in a separate document. New types of identity introduced to SIP may in turn have some privacy requirements, but it does not follow from this that a privacy document is the right place to propose all kinds of new identities. If these identities are useful outside the context of privacy, that might have suggested that this is a separable issue. The privacy considerations for these new identities can be explored subsequent to their acceptance by the SIP community. For the time being, I think this parameter is superfluous and confusing, and it should be removed. - rpi-privacy: To me this parameter is really the crux of the draft - that and the fact that the RPID header can be added, deleted or modified only by proxy servers. However, it hasn't been clear to me why the privacy parameter is defined only within the scope of the RPID header. If we would like this draft to have general applicability to the privacy problem, perhaps it would be better if "privacy" were defined as a general URI header. The RPID header should usually, but perhaps not always, contain a URI that has a "privacy" parameter. I'd be interested to hear if there are scenarios within the applicability of the draft in which the RPID header should be used without a "privacy" parameter - perhaps the presence of "privacy" in RPID could be a MUST. However, I see no reason why it might not make sense for other URIs than those in an RPID to contain the "privacy" parameter. - Extensibility: While it's generally desirable for a mechanism to be extensible (you should reuse existing mechanisms to solve new problems if you can), sometimes extensibility can be confusing. Given the strict applicability that precedes sip-privacy-04, it isn't really clear how much extensibility is desirable - and at what point extensibility would invite the use of RPID to architectures outside of that applicability. While I applaud the move in sip-privacy-04 to require that extensions to the RPID be published in an RFC, I'm not sure that this alone is sufficient. The middle two parameters I've discussed above (rpi-ip-type and rpi-pty-type) are extensible in privacy-04. Given that I'm a little queasy on their current values (not to mention their overall relevance), it would probably go without saying that I'm unsure about extending them further. These reservations do not however carry over to the 'rpi-privacy' parameter - I believe that should be extensible. - RPID-Privacy: The need to assert any of the above parameters in the RPID-Privacy should probably also be revisited in the light of the considerations above. I think it's pretty clear that an RPID-Privacy header should express the wishes of the originating user to keep their identity private in this message, and it isn't clear why a user would want to tell the network to, say, keep some other user's identity private. If this is needed, the draft should explain when it would be useful. - Gobbledygook in From: The motivation for cryptographically random garbage in the From header may have gone away in light of the mandate for the 'tag' parameter in the From field of requests in rfc2543bis, which guarantees that dialog identification will be globally unique. I would suggest instead that the From header for an anonymous request should be completely homogenous, so all private From headers look alike. rfc2543bis09 actually contains examples of both - in some places, anonymous requests use an apparently random user and/or host, in other places something standard like 'anonymous@localhost'. I would recommend the latter, if only because you already have to build something globally unique for the tag - or at the very least, that this point be revisited in light of bis. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 18 13:21:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14173 for ; Mon, 18 Mar 2002 13:21:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23758 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 13:21:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21822; Mon, 18 Mar 2002 12:50:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21791 for ; Mon, 18 Mar 2002 12:50:52 -0500 (EST) Received: from relay4.nyc2.aens.net (relay4.nyc2.attens.net [63.240.1.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13264; Mon, 18 Mar 2002 12:50:48 -0500 (EST) Received: from email.masconit.com (email.masconit.com [12.107.104.100]) by relay4.nyc2.aens.net (8.11.6/8.11.6) with ESMTP id g2IHobk28537; Mon, 18 Mar 2002 17:50:38 GMT Received: from RANJIT (12.107.104.95 [12.107.104.95]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H17BGW75; Mon, 18 Mar 2002 11:50:37 -0600 Reply-To: From: "Ranjit Avasarala" To: , Cc: Subject: RE: [Sip] Comments on SIP-URL grammar Date: Mon, 18 Mar 2002 11:54:55 -0600 Message-ID: <000f01c1cea6$0426cff0$9800000a@RANJIT> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <65256B80.002C628C.00@sampark.hss.hns.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi since in userinfo : is in [: it implies it is optional so sio url can be as sip:user@myserver.com but I don't understand why password should have zero characters. Regards Ranjit -----Original Message----- From: mkramanna@hss.hns.com [mailto:mkramanna@hss.hns.com] Sent: Monday, March 18, 2002 2:13 AM To: Internet-Drafts@ietf.org Cc: sip@ietf.org Subject: [Sip] Comments on SIP-URL grammar Hi, In the draft it is said that the password field of userinfo can have zero characters. If the user specifies ":" after the user field, why is it that zero characters are allowed for the password field. Shouldn't it be one or more characters? Similarly shouldn't it be one or more characters for the userfield also. SIP-URL = "sip:" [ userinfo "@" ] hostport url-parameters [ headers ] userinfo = [ user | telephone-subscriber [ ":" password ]] user = *( unreserved | escaped | user-unreserved ) password = *( unreserved | escaped | " " | "=" | "+" | "$" | "," ) According to the grammar the following examples are valid. sip:user:@myserver.com sip::password@myserver.com regards, mohan This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. 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 using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 18 14:09:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15864 for ; Mon, 18 Mar 2002 14:09:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27792 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 14:10:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25260; Mon, 18 Mar 2002 13:41:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25226 for ; Mon, 18 Mar 2002 13:41:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14850 for ; Mon, 18 Mar 2002 13:41:00 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2IIf0l27978; Mon, 18 Mar 2002 12:41:00 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2IIf0F21537; Mon, 18 Mar 2002 12:41:00 -0600 (CST) Received: from lmf.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA29225; Mon, 18 Mar 2002 12:40:58 -0600 (CST) Message-ID: <3C963557.CF5285A7@lmf.ericsson.se> Date: Mon, 18 Mar 2002 20:43:35 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 References: <200203180544.AAA21400@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, we have three issues here. 1) The first one is update glare: > --INVITE (offer)---> --UPDATE (offer)---> > X-183 (answer)--- X-200 (answer)--- > <--UPDATE (offer)--- <--UPDATE (offer)--- > -----491-----------> -----491-----------> > > Thus there will always be the case (lost 200 to UPDATE) where one > side thinks an offer is pending and the other thinks it has been > answered. Error 491 will resolve it. Forcing the UAS to wait for > the PRACK solves one but not the other. The 491 mechanism was creates to resolve this problem, so I believe we do not need to specify anything new. 2) The second one is the UPDATE-PRACK glare (both carrying an offer). This is solved by making the UAS to wait for the PRACK before sending a new UPDATE. 3) The third one is somehow related to the previous one, but there is not glare. The UAS receives an offer in the PRACK and it wants to refuse it. I believe that refusing the PRACK with an status code that says (session description not acceptable) is not a good thing. Therefore, since offers in PRACK cannot be rejected, I would rule them out completely... yes, this is less efficient, but I still think it is the right thing to do. In general, this problem of not being able to refuse an offer is already present in SIP every time an offer appears in a response. That's why we RECOMMEND that offers sent in responses are "pretty similar" to the session description which is already in use. I would not like to extend the same problem to offers in PRACKs as well. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 18 14:16:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16087 for ; Mon, 18 Mar 2002 14:16:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28177 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 14:16:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26140; Mon, 18 Mar 2002 13:54:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26110 for ; Mon, 18 Mar 2002 13:54:55 -0500 (EST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15360 for ; Mon, 18 Mar 2002 13:54:51 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 1D7604CEEB; Mon, 18 Mar 2002 13:54:54 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA02654; Mon, 18 Mar 2002 13:54:51 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA23902; Mon, 18 Mar 2002 13:54:35 -0500 (EST) Date: Mon, 18 Mar 2002 13:54:35 -0500 (EST) Message-Id: <200203181854.NAA23902@fish.research.att.com> To: Gonzalo.Camarillo@lmf.ericsson.se Cc: sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Therefore, since offers in PRACK cannot be rejected, I would rule them > out completely... yes, this is less efficient, but I still think it is > the right thing to do. is this the start of rfc3262bis-00? Bill Marshall wtm@research.att.com -----original message----- Date: Mon, 18 Mar 2002 20:43:35 +0200 From: Gonzalo Camarillo To: William Marshall Cc: jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 Hi, we have three issues here. 1) The first one is update glare: > --INVITE (offer)---> --UPDATE (offer)---> > X-183 (answer)--- X-200 (answer)--- > <--UPDATE (offer)--- <--UPDATE (offer)--- > -----491-----------> -----491-----------> > > Thus there will always be the case (lost 200 to UPDATE) where one > side thinks an offer is pending and the other thinks it has been > answered. Error 491 will resolve it. Forcing the UAS to wait for > the PRACK solves one but not the other. The 491 mechanism was creates to resolve this problem, so I believe we do not need to specify anything new. 2) The second one is the UPDATE-PRACK glare (both carrying an offer). This is solved by making the UAS to wait for the PRACK before sending a new UPDATE. 3) The third one is somehow related to the previous one, but there is not glare. The UAS receives an offer in the PRACK and it wants to refuse it. I believe that refusing the PRACK with an status code that says (session description not acceptable) is not a good thing. Therefore, since offers in PRACK cannot be rejected, I would rule them out completely... yes, this is less efficient, but I still think it is the right thing to do. In general, this problem of not being able to refuse an offer is already present in SIP every time an offer appears in a response. That's why we RECOMMEND that offers sent in responses are "pretty similar" to the session description which is already in use. I would not like to extend the same problem to offers in PRACKs as well. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 18 14:16:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16144 for ; Mon, 18 Mar 2002 14:16:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28213 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 14:16:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25895; Mon, 18 Mar 2002 13:49:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25851 for ; Mon, 18 Mar 2002 13:49:03 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15159 for ; Mon, 18 Mar 2002 13:48:55 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2IImPi09797; Mon, 18 Mar 2002 12:48:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2IImPq25412; Mon, 18 Mar 2002 12:48:25 -0600 (CST) Received: from lmf.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA29819; Mon, 18 Mar 2002 12:48:23 -0600 (CST) Message-ID: <3C963715.C8B6A695@lmf.ericsson.se> Date: Mon, 18 Mar 2002 20:51:01 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: salreyca@teleco.upv.es CC: sip@ietf.org Subject: Re: [Sip] SDP in unreliable 18x References: <3C95D19F.18566.5BD15C@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Salva Rey Calatayud wrote: > I never mentioned the UPDATE method being used here. could > you answer my question why a second 183 rel conveying a second > offer is illegal? feel free to give references to sections in drafts. > Because the UAC may be issuing an UPDATE at the same time as you are sending this reliable response. You would have a glare condition in this case, and since you cannot refuse a response saying "we have a glare situation", the glare cannot be solver. You could say that the UPDATe always win, but this does not seem like a good solution. > How many lines in the update draft mention that a UAS can > issue an UPDATE? A UAS does not issue requests. UAS generate responses. If the "callee's UA" generates an UPDATE, it is acting as a UAC. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Mon Mar 18 14:39:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16950 for ; Mon, 18 Mar 2002 14:39:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00118 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 14:39:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA28300; Mon, 18 Mar 2002 14:17:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01134 for ; Sat, 16 Mar 2002 01:28:52 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21095 for ; Sat, 16 Mar 2002 01:28:49 -0500 (EST) From: jh@lohi.eng.song.fi Received: from harjus.eng.song.fi ([195.10.149.20]) by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian)) id 16m7gB-0002ZF-00; Sat, 16 Mar 2002 08:28:35 +0200 To: xchen2@lucent.com CC: sip@ietf.org Message-Id: Date: Sat, 16 Mar 2002 08:28:35 +0200 Subject: [Sip] rsvp or manyfolks in 3gpp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org xin, from your message i get an impression that rsvp is not mandatory in 3gpp terminals: > I am familiar with the 3GPP SIP architecture, our terminals don't use > RSVP, ... last fall i wrote on the sip mailing list: > i met yesterday a person who works for a big mobile phone/network vendor > and when i asked about manyfolks, he said that the 3gpp indeed has > adopted it, but that it is not a mandatory part of the spec and that > this vendor has no intention to use it in its own products. to which Miguel Garcia from ericsson replied: > Good luck to that vendor. I can tell you that manyfolks IS mandatory > in 3GPP, so if somebody designs a terminal that does not support > manyfolks, is not going to be 3GPP compliant. I believe the person you > spoke to is miss-informed. i'm now a bit buzzled here? is it so that an e-2-e reservation according to manyfolks is mandatory in 3gpp terminals, but the reservation protocol doesn't need to be rsvp? if so, can each handset vendor invent their own or what? -- 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 daemon@ns.ietf.org Mon Mar 18 15:04:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18162 for ; Mon, 18 Mar 2002 15:04:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA02151 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 15:04:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00505; Mon, 18 Mar 2002 14:47:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00475 for ; Mon, 18 Mar 2002 14:47:22 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17300 for ; Mon, 18 Mar 2002 14:47:18 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2IJkoi12199; Mon, 18 Mar 2002 13:46:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2IJko511783; Mon, 18 Mar 2002 13:46:50 -0600 (CST) Received: from lmf.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA05258; Mon, 18 Mar 2002 13:46:48 -0600 (CST) Message-ID: <3C9644C5.CC3E777B@lmf.ericsson.se> Date: Mon, 18 Mar 2002 21:49:25 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org, Jonathan Rosemberg Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05 References: <200203181854.NAA23902@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, William Marshall wrote: > > > Therefore, since offers in PRACK cannot be rejected, I would rule them > > out completely... yes, this is less efficient, but I still think it is > > the right thing to do. > > is this the start of rfc3262bis-00? There is not such an RFC in the archives, so there is no reason for a bis. http://www.ietf.org/iesg/1rfc_index.txt Regarding http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-06.txt You are right that we may need a small modification. If this suggestion was taken into account, it would be necessary to remove the following lines from the draft: "If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK." But it may be too late for doing so, so we may have to live without refusing offers in PRACKs. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 18 16:15:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20525 for ; Mon, 18 Mar 2002 16:15:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07293 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 16:15:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05735; Mon, 18 Mar 2002 15:56:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05704 for ; Mon, 18 Mar 2002 15:56:27 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19812 for ; Mon, 18 Mar 2002 15:56:22 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2IKuJl16667; Mon, 18 Mar 2002 14:56:19 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2IKuJF25132; Mon, 18 Mar 2002 14:56:19 -0600 (CST) Received: from lmf.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA11756; Mon, 18 Mar 2002 14:56:16 -0600 (CST) Message-ID: <3C96550D.F5A36053@lmf.ericsson.se> Date: Mon, 18 Mar 2002 22:58:53 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Dean Willis'" , sip@ietf.org, wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: Re: [Sip] WGLC for Manyfolks draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark, > I still think there is no reason in principle why a UA needs to > understand the pre-condition type in order to be able to deal with the > other end requiring local pre-conditions. we will discuss this point in the SIP WG meeting this evening. I have prepared a couple of slides about it. I will add your comments regarding the language for the "value" of the attributes. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Mar 18 16:21:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20811 for ; Mon, 18 Mar 2002 16:21:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA07463 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 16:21:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06941; Mon, 18 Mar 2002 16:09:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06910 for ; Mon, 18 Mar 2002 16:09:29 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20244 for ; Mon, 18 Mar 2002 16:09:23 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2IL9Qq04310 for ; Mon, 18 Mar 2002 16:09:26 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 21:09:25 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0049927BB@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: jh@lohi.eng.song.fi, "Chen, Xin (Xin)" Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Date: Mon, 18 Mar 2002 21:09:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org See in line please. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] Sent: 16 March 2002 6:29 To: xchen2@lucent.com Cc: sip@ietf.org Subject: [Sip] rsvp or manyfolks in 3gpp xin, from your message i get an impression that rsvp is not mandatory in 3gpp terminals: [xc] Correct. RSVP or any other extra signalling protocol used for QoS reservation which will cost radio resource will not be implemented in terminals. > I am familiar with the 3GPP SIP architecture, our terminals don't use > RSVP, ... last fall i wrote on the sip mailing list: > i met yesterday a person who works for a big mobile phone/network vendor > and when i asked about manyfolks, he said that the 3gpp indeed has > adopted it, but that it is not a mandatory part of the spec and that > this vendor has no intention to use it in its own products. to which Miguel Garcia from ericsson replied: > Good luck to that vendor. I can tell you that manyfolks IS mandatory > in 3GPP, so if somebody designs a terminal that does not support > manyfolks, is not going to be 3GPP compliant. I believe the person you > spoke to is miss-informed. [xc] Miguel was right that we need manyfolks because it provides the precondition so that calling user can prevent the called user from ringing until the calling user completes the PDP context activation. But this doesn't mean that 3GPP terminals have to support any QoS reservation protocol. i'm now a bit buzzled here? is it so that an e-2-e reservation according to manyfolks is mandatory in 3gpp terminals, but the reservation protocol doesn't need to be rsvp? if so, can each handset vendor invent their own or what? [xc]Precondition is mandatory in 3GPP terminals, but not any QoS reservation protocol. Only PDP context activation message will go to signalling channel and free of charge, but if the terminal wants to use RSVP or something similar, it is fine, but the RSVP messages will not be sent on signalling channel but user traffic channel and get charged. -- 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 daemon@ns.ietf.org Mon Mar 18 16:38:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21307 for ; Mon, 18 Mar 2002 16:38:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09026 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 16:38:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07522; Mon, 18 Mar 2002 16:22:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07495 for ; Mon, 18 Mar 2002 16:22:32 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20847 for ; Mon, 18 Mar 2002 16:22:26 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2ILLQi00129; Mon, 18 Mar 2002 15:21:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2ILLQq21904; Mon, 18 Mar 2002 15:21:26 -0600 (CST) Received: from lmf.ericsson.se (rmt160186.am.ericsson.se [138.85.160.186]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA14308; Mon, 18 Mar 2002 15:21:24 -0600 (CST) Message-ID: <3C965AF0.6C55AA0A@lmf.ericsson.se> Date: Mon, 18 Mar 2002 23:24:00 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: jh@lohi.eng.song.fi CC: xchen2@lucent.com, sip@ietf.org Subject: Re: [Sip] rsvp or manyfolks in 3gpp References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha, Manyfolks is still mandatory in 3GPP, but not the e2e status type. The segmented status type will be used instead. This means that with QoS in the access networks but not in the backbone the call can proceed. Regards, Gonzalo jh@lohi.eng.song.fi wrote: > > xin, > > from your message i get an impression that rsvp is not mandatory in 3gpp > terminals: > > > I am familiar with the 3GPP SIP architecture, our terminals don't use > > RSVP, ... > > last fall i wrote on the sip mailing list: > > > i met yesterday a person who works for a big mobile phone/network vendor > > and when i asked about manyfolks, he said that the 3gpp indeed has > > adopted it, but that it is not a mandatory part of the spec and that > > this vendor has no intention to use it in its own products. > > to which Miguel Garcia from ericsson replied: > > > Good luck to that vendor. I can tell you that manyfolks IS mandatory > > in 3GPP, so if somebody designs a terminal that does not support > > manyfolks, is not going to be 3GPP compliant. I believe the person you > > spoke to is miss-informed. > > i'm now a bit buzzled here? is it so that an e-2-e reservation > according to manyfolks is mandatory in 3gpp terminals, but the > reservation protocol doesn't need to be rsvp? if so, can each handset > vendor invent their own or what? > > -- 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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Mon Mar 18 16:57:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21783 for ; Mon, 18 Mar 2002 16:57:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA09896 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 16:57:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09210; Mon, 18 Mar 2002 16:42:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09176 for ; Mon, 18 Mar 2002 16:42:37 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21428 for ; Mon, 18 Mar 2002 16:42:30 -0500 (EST) Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian)) id 16n4tf-0003WA-00; Mon, 18 Mar 2002 23:42:27 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.24387.365044.489921@lohi.eng.song.fi> Date: Mon, 18 Mar 2002 23:42:27 +0200 To: "Chen, Xin (Xin)" Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp In-Reply-To: <475FF955A05DD411980D00508B6D5FB0049927BB@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0049927BB@en0033exch001u.uk.lucent.com> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chen, Xin (Xin) writes: > [xc] Miguel was right that we need manyfolks because it provides the > precondition so that calling user can prevent the called user from ringing > until the calling user completes the PDP context activation. But this > doesn't mean that 3GPP terminals have to support any QoS reservation > protocol. that makes sense, but i still don't understand why anything beyond basic sip is needed for this purpose. why can't it be a standard behavior of a 3gpp terminal always first try to setup a real time pdp context for the media and send the invite or generate ringing only if the setup succeeds? -- 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 daemon@ns.ietf.org Mon Mar 18 17:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22500 for ; Mon, 18 Mar 2002 17:16:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA12358 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 17:16:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10102; Mon, 18 Mar 2002 16:59:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10071 for ; Mon, 18 Mar 2002 16:59:32 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21856 for ; Mon, 18 Mar 2002 16:59:26 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2ILxTq20920 for ; Mon, 18 Mar 2002 16:59:29 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Mar 2002 21:59:28 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0049927D2@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Juha Heinanen , "Chen, Xin (Xin)" Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Date: Mon, 18 Mar 2002 21:59:27 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Good question. There are two types of PDP contexts for a 3GPP IMS terminal, One is used for SIP signalling only which is free of charge, and another one is used for media traffic. Each PDP context has to associate with a set of QoS parameters. In order to activate the media traffic PDP context, the users has to know the QoS prameters needed for this session (media type, codec, bandwidth.....), these information is from the SDP exchange between terminals which is carried in SIP signalling message in the signalling PDP context. This is why you have to have signalling first, then real time traffic PDP context comes into play. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] Sent: 18 March 2002 21:42 To: Chen, Xin (Xin) Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Chen, Xin (Xin) writes: > [xc] Miguel was right that we need manyfolks because it provides the > precondition so that calling user can prevent the called user from ringing > until the calling user completes the PDP context activation. But this > doesn't mean that 3GPP terminals have to support any QoS reservation > protocol. that makes sense, but i still don't understand why anything beyond basic sip is needed for this purpose. why can't it be a standard behavior of a 3gpp terminal always first try to setup a real time pdp context for the media and send the invite or generate ringing only if the setup succeeds? -- 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 daemon@ns.ietf.org Mon Mar 18 17:21:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22763 for ; Mon, 18 Mar 2002 17:21:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13041 for sip-archive@odin.ietf.org; Mon, 18 Mar 2002 17:22:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11620; Mon, 18 Mar 2002 17:05:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11590 for ; Mon, 18 Mar 2002 17:05:42 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22124 for ; Mon, 18 Mar 2002 17:05:36 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2IM58h19005; Mon, 18 Mar 2002 14:05:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABE19613; Mon, 18 Mar 2002 14:02:43 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA08741; Mon, 18 Mar 2002 14:05:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15510.25746.626321.333104@thomasm-u1.cisco.com> Date: Mon, 18 Mar 2002 14:05:06 -0800 (PST) To: "Chen, Xin (Xin)" Cc: Juha Heinanen , sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp In-Reply-To: <475FF955A05DD411980D00508B6D5FB0049927D2@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB0049927D2@en0033exch001u.uk.lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Um, folks, before you eject the baby with the bathwater, somebody better do some explaining how it is that a SIP appliance connected through a mobile router convinces that mobile router to put my RTP bits on the A-list. We're supposedly here for a slightly longer term thinking than the range of the 3GPP moment. Mike Chen, Xin (Xin) writes: > Good question. > > There are two types of PDP contexts for a 3GPP IMS terminal, > > One is used for SIP signalling only which is free of charge, and another one > is used for media traffic. > > Each PDP context has to associate with a set of QoS parameters. > > In order to activate the media traffic PDP context, the users has to know > the QoS prameters needed for this session (media type, codec, > bandwidth.....), these information is from the SDP exchange between > terminals which is carried in SIP signalling message in the signalling PDP > context. This is why you have to have signalling first, then real time > traffic PDP context comes into play. > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: 18 March 2002 21:42 > To: Chen, Xin (Xin) > Cc: sip@ietf.org > Subject: RE: [Sip] rsvp or manyfolks in 3gpp > > > Chen, Xin (Xin) writes: > > > [xc] Miguel was right that we need manyfolks because it provides the > > precondition so that calling user can prevent the called user from > ringing > > until the calling user completes the PDP context activation. But this > > doesn't mean that 3GPP terminals have to support any QoS reservation > > protocol. > > that makes sense, but i still don't understand why anything beyond basic > sip is needed for this purpose. why can't it be a standard behavior of > a 3gpp terminal always first try to setup a real time pdp context for > the media and send the invite or generate ringing only if the setup > succeeds? > > -- 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 daemon@optimus.ietf.org Tue Mar 19 03:56:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17760 for ; Tue, 19 Mar 2002 03:56:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29087 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 03:56:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25242; Tue, 19 Mar 2002 02:59:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25190 for ; Tue, 19 Mar 2002 02:59:42 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16691 for ; Tue, 19 Mar 2002 02:59:25 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2J7wti16125; Tue, 19 Mar 2002 01:58:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2J7wsU14182; Tue, 19 Mar 2002 01:58:54 -0600 (CST) Received: from lmf.ericsson.se (racom160248.am.ericsson.se [138.85.160.248]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id BAA08970; Tue, 19 Mar 2002 01:58:51 -0600 (CST) Message-ID: <3C96F057.6AE2D67@lmf.ericsson.se> Date: Tue, 19 Mar 2002 10:01:27 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , "Brian Rosenberg (EUS)" , Dean Willis , Joerg Ott , rohan@cisco.com CC: Henning Schulzrinne , oran@cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Requirements on Reason information. New I-D Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chairmen, I presented the Reason header field draft today in the SIP WG meeting: http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt Some folks considered that the requirements for this work were not clear enough, so I was asked by the chairmen to write a set of requirements. We agreed that there was no need to wait for the next IETF meeting in order to progress such a requirements draft. Discussions in the mailing list were encouraged. I have put together an I-D with those requirements. http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt I would like to know if these requirements are what you expected or if, on the other hand, you wanted something else... I intend to submit this draft, including the comments I may receive, on Monday. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Tue Mar 19 06:47:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19767 for ; Tue, 19 Mar 2002 06:47:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA08710 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 06:47:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06197; Tue, 19 Mar 2002 05:58:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06166 for ; Tue, 19 Mar 2002 05:58:56 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19206 for ; Tue, 19 Mar 2002 05:58:40 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2JAwAH01660; Tue, 19 Mar 2002 11:58:10 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2JAvc521892; Tue, 19 Mar 2002 10:57:38 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 10:58:11 -0000 Message-ID: From: "Mark Watson" To: "'Michael Thomas'" , "Chen, Xin (Xin)" Cc: Juha Heinanen , sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Date: Tue, 19 Mar 2002 10:58:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CF34.F3795A30" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CF34.F3795A30 Content-Type: text/plain I think reports of the short-term demise of 3GPP are grossly exaggerated, as they say. 3GPP Release 5 does not *mandate* rsvp, but it is indeed hard to see how else a SIP application running in one place will communicate its QoS requests to the UMTS access device it is using, be this a mobile router or just a PCMCIA card. Unless, that is, you have a SIP client modified to support 3GPP-specific QoS APIs & a protocol to carry those requests between devices. ...Mark > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: 18 March 2002 22:05 > To: Chen, Xin (Xin) > Cc: Juha Heinanen; sip@ietf.org > Subject: RE: [Sip] rsvp or manyfolks in 3gpp > > > > Um, folks, before you eject the baby with the > bathwater, somebody better do some explaining how > it is that a SIP appliance connected through a > mobile router convinces that mobile router to put > my RTP bits on the A-list. > > We're supposedly here for a slightly longer term > thinking than the range of the 3GPP moment. > > Mike > > Chen, Xin (Xin) writes: > > Good question. > > > > There are two types of PDP contexts for a 3GPP IMS terminal, > > > > One is used for SIP signalling only which is free of > charge, and another one > > is used for media traffic. > > > > Each PDP context has to associate with a set of QoS parameters. > > > > In order to activate the media traffic PDP context, the > users has to know > > the QoS prameters needed for this session (media type, codec, > > bandwidth.....), these information is from the SDP exchange between > > terminals which is carried in SIP signalling message in > the signalling PDP > > context. This is why you have to have signalling first, > then real time > > traffic PDP context comes into play. > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > > Sent: 18 March 2002 21:42 > > To: Chen, Xin (Xin) > > Cc: sip@ietf.org > > Subject: RE: [Sip] rsvp or manyfolks in 3gpp > > > > > > Chen, Xin (Xin) writes: > > > > > [xc] Miguel was right that we need manyfolks because it > provides the > > > precondition so that calling user can prevent the > called user from > > ringing > > > until the calling user completes the PDP context > activation. But this > > > doesn't mean that 3GPP terminals have to support any > QoS reservation > > > protocol. > > > > that makes sense, but i still don't understand why > anything beyond basic > > sip is needed for this purpose. why can't it be a > standard behavior of > > a 3gpp terminal always first try to setup a real time pdp > context for > > the media and send the invite or generate ringing only if the setup > > succeeds? > > > > -- 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 > ------_=_NextPart_001_01C1CF34.F3795A30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] rsvp or manyfolks in 3gpp

I think reports of the short-term demise of 3GPP are = grossly exaggerated, as they say.

3GPP Release 5 does not *mandate* rsvp, but it is = indeed hard to see how else a SIP application running in one place will = communicate its QoS requests to the UMTS access device it is using, be = this a mobile router or just a PCMCIA card.

Unless, that is, you have a SIP client modified to = support 3GPP-specific QoS APIs & a protocol to carry those requests = between devices.

...Mark

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: 18 March 2002 22:05
> To: Chen, Xin (Xin)
> Cc: Juha Heinanen; sip@ietf.org
> Subject: RE: [Sip] rsvp or manyfolks in = 3gpp
>
>
>
> Um, folks, before you eject the baby with = the
> bathwater, somebody better do some explaining = how
> it is that a SIP appliance connected through = a
> mobile router convinces that mobile router to = put
> my RTP bits on the A-list.
>
> We're supposedly here for a slightly longer = term
> thinking than the range of the 3GPP = moment.
>
>         = Mike
>
> Chen, Xin (Xin) writes:
>  > Good question.
>  >
>  > There are two types of PDP contexts = for a 3GPP IMS terminal,
>  >
>  > One is used for SIP signalling only = which is free of
> charge, and another one
>  > is used for media traffic.
>  >
>  > Each PDP context has to associate = with a set of QoS parameters.
>  >
>  > In order to activate the media = traffic PDP context, the
> users has to know
>  > the QoS prameters needed for this = session (media type, codec,
>  > bandwidth.....), these information = is from the SDP exchange between
>  > terminals which is carried in SIP = signalling message in
> the signalling PDP
>  > context. This is why you have to = have signalling first,
> then real time
>  > traffic PDP context comes into = play.
>  >
>  > Xin Chen
>  >
>  > Lucent Technologies
>  > Tel: +44 1793 883137
>  > Mobile: +44 7799 034668
>  >
>  >
>  > -----Original Message-----
>  > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
>  > Sent: 18 March 2002 21:42
>  > To: Chen, Xin (Xin)
>  > Cc: sip@ietf.org
>  > Subject: RE: [Sip] rsvp or manyfolks = in 3gpp
>  >
>  >
>  > Chen, Xin (Xin) writes:
>  >
>  >  > [xc] Miguel was right = that we need manyfolks because it
> provides the
>  >  > precondition so that = calling user can prevent the
> called user from
>  > ringing
>  >  > until the calling user = completes the PDP context
> activation. But this
>  >  > doesn't mean that 3GPP = terminals have to support any
> QoS reservation
>  >  > protocol.
>  >
>  > that makes sense, but i still don't = understand why
> anything beyond basic
>  > sip is needed for this = purpose.  why can't it be a
> standard behavior of
>  > a 3gpp terminal always first try to = setup a real time pdp
> context for
>  > the media and send the invite or = generate ringing only if the setup
>  > succeeds?
>  >
>  > -- 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
>

------_=_NextPart_001_01C1CF34.F3795A30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 08:08:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20871 for ; Tue, 19 Mar 2002 08:08:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13257 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 08:08:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10807; Tue, 19 Mar 2002 07:25:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10759 for ; Tue, 19 Mar 2002 07:25:49 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20345 for ; Tue, 19 Mar 2002 07:25:47 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA08132; Tue, 19 Mar 2002 07:25:30 -0500 (EST) Received: from cs.columbia.edu (slip-12-64-54-130.mis.prserv.net [12.64.54.130]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2JCPMPm026436 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Mar 2002 07:25:26 -0500 (EST) Message-ID: <3C972E19.F35F6A56@cs.columbia.edu> Date: Tue, 19 Mar 2002 06:24:57 -0600 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , "Brian Rosenberg (EUS)" , Dean Willis , Joerg Ott , rohan@cisco.com, oran@cisco.com Subject: Re: [Sip] Requirements on Reason information. New I-D References: <3C96F057.6AE2D67@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for putting this together. I'm not sure MUST/SHOULD are appropriate for requirements drafts, but this is presumably not meant for RFC publication, so it probably doesn't matter. Gonzalo Camarillo wrote: > > Chairmen, > > I presented the Reason header field draft today in the SIP WG meeting: > http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt > > Some folks considered that the requirements for this work were not clear > enough, so I was asked by the chairmen to write a set of requirements. > We agreed that there was no need to wait for the next IETF meeting in > order to progress such a requirements draft. Discussions in the mailing > list were encouraged. > > I have put together an I-D with those requirements. > > http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt > > I would like to know if these requirements are what you expected or if, > on the other hand, you wanted something else... > > I intend to submit this draft, including the comments I may receive, on > Monday. > > Thanks, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 08:11:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20954 for ; Tue, 19 Mar 2002 08:11:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13428 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 08:11:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10448; Tue, 19 Mar 2002 07:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10394 for ; Tue, 19 Mar 2002 07:15:19 -0500 (EST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20158 for ; Tue, 19 Mar 2002 07:15:12 -0500 (EST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g2JC5IU30341; Tue, 19 Mar 2002 14:05:19 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Mar 2002 14:14:30 +0200 Message-ID: From: "Fuxbruner, Amihay" To: "'Chen, Xin (Xin)'" , Juha Heinanen Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Date: Tue, 19 Mar 2002 14:14:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CF3F.9EC4A020" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CF3F.9EC4A020 Content-Type: text/plain; charset="iso-8859-1" Is there any QoS requirements for the signaling channel ? Amihay Fuxbruner System Engineering - Signaling R&D Comverse -----Original Message----- From: Chen, Xin (Xin) [mailto:xchen2@lucent.com] Sent: Monday, March 18, 2002 11:59 PM To: Juha Heinanen; Chen, Xin (Xin) Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Good question. There are two types of PDP contexts for a 3GPP IMS terminal, One is used for SIP signalling only which is free of charge, and another one is used for media traffic. Each PDP context has to associate with a set of QoS parameters. In order to activate the media traffic PDP context, the users has to know the QoS prameters needed for this session (media type, codec, bandwidth.....), these information is from the SDP exchange between terminals which is carried in SIP signalling message in the signalling PDP context. This is why you have to have signalling first, then real time traffic PDP context comes into play. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] Sent: 18 March 2002 21:42 To: Chen, Xin (Xin) Cc: sip@ietf.org Subject: RE: [Sip] rsvp or manyfolks in 3gpp Chen, Xin (Xin) writes: > [xc] Miguel was right that we need manyfolks because it provides the > precondition so that calling user can prevent the called user from ringing > until the calling user completes the PDP context activation. But this > doesn't mean that 3GPP terminals have to support any QoS reservation > protocol. that makes sense, but i still don't understand why anything beyond basic sip is needed for this purpose. why can't it be a standard behavior of a 3gpp terminal always first try to setup a real time pdp context for the media and send the invite or generate ringing only if the setup succeeds? -- 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 ------_=_NextPart_001_01C1CF3F.9EC4A020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] rsvp or manyfolks in 3gpp

Is there any QoS requirements for the signaling = channel ?

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse


-----Original Message-----
From: Chen, Xin (Xin) [mailto:xchen2@lucent.com]
Sent: Monday, March 18, 2002 11:59 PM
To: Juha Heinanen; Chen, Xin (Xin)
Cc: sip@ietf.org
Subject: RE: [Sip] rsvp or manyfolks in 3gpp


Good question.

There are two types of PDP contexts for a 3GPP IMS = terminal,

One is used for SIP signalling only which is free of = charge, and another one
is used for media traffic.

Each PDP context has to associate with a set of QoS = parameters.

In order to activate the media traffic PDP context, = the users has to know
the QoS prameters needed for this session (media = type, codec,
bandwidth.....), these information is from the SDP = exchange between
terminals which is carried in SIP signalling message = in the signalling PDP
context. This is why you have to have signalling = first, then real time
traffic PDP context comes into play.

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668


-----Original Message-----
From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
Sent: 18 March 2002 21:42
To: Chen, Xin (Xin)
Cc: sip@ietf.org
Subject: RE: [Sip] rsvp or manyfolks in 3gpp


Chen, Xin (Xin) writes:

 > [xc] Miguel was right that we need = manyfolks because it provides the
 > precondition so that calling user can = prevent the called user from
ringing
 > until the calling user completes the PDP = context activation. But this
 > doesn't mean that 3GPP terminals have to = support any QoS reservation
 > protocol.

that makes sense, but i still don't understand why = anything beyond basic
sip is needed for this purpose.  why can't it = be a standard behavior of
a 3gpp terminal always first try to setup a real = time pdp context for
the media and send the invite or generate ringing = only if the setup
succeeds?

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

------_=_NextPart_001_01C1CF3F.9EC4A020-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 08:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20984 for ; Tue, 19 Mar 2002 08:13:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA13504 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 08:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11779; Tue, 19 Mar 2002 07:45:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11724 for ; Tue, 19 Mar 2002 07:44:24 -0500 (EST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20558 for ; Tue, 19 Mar 2002 07:44:20 -0500 (EST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g2JCZ0U31165 for ; Tue, 19 Mar 2002 14:35:00 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Mar 2002 14:44:12 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] Question on UPDATE after INVITE completion Date: Tue, 19 Mar 2002 14:44:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CF43.C498EF00" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CF43.C498EF00 Content-Type: text/plain; charset="iso-8859-1" What is the purpose of sending UPDATE after INVITE completion ? Is this another way for re-INVITE ? Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C1CF43.C498EF00 Content-Type: text/html; charset="iso-8859-1" [Sip] Question on UPDATE after INVITE completion

What is the purpose of sending UPDATE after INVITE completion ?
Is this another way for re-INVITE ?

Thanks,

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C1CF43.C498EF00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 10:01:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23602 for ; Tue, 19 Mar 2002 10:01:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21548 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 10:01:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19731; Tue, 19 Mar 2002 09:41:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19688 for ; Tue, 19 Mar 2002 09:41:18 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23038 for ; Tue, 19 Mar 2002 09:41:14 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2JEebi27389; Tue, 19 Mar 2002 08:40:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2JEeb215082; Tue, 19 Mar 2002 08:40:37 -0600 (CST) Received: from lmf.ericsson.se (rmt160122.am.ericsson.se [138.85.160.122]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA14713; Tue, 19 Mar 2002 08:40:36 -0600 (CST) Message-ID: <3C974E86.A02C22D5@lmf.ericsson.se> Date: Tue, 19 Mar 2002 16:43:18 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: sip@ietf.org Subject: Re: [Sip] Question on UPDATE after INVITE completion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Fuxbruner, Amihay" wrote: > > What is the purpose of sending UPDATE after INVITE completion ? > Is this another way for re-INVITE ? UPDATE involves only two messages, so it can be useful for saving bandwidth. re-INVITE is still needed, though, because in some scenarios you cannot provide an offer in the re-INVITE, and you have to wait for an offer in the response. UPDATe does not support this three-way-handshake. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 10:20:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24104 for ; Tue, 19 Mar 2002 10:20:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22790 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 10:20:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22037; Tue, 19 Mar 2002 10:07:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21936 for ; Tue, 19 Mar 2002 10:07:36 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23751 for ; Tue, 19 Mar 2002 10:07:33 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JF74d10199; Tue, 19 Mar 2002 07:07:04 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA05884; Tue, 19 Mar 2002 07:06:57 -0800 (PST) Message-ID: <3C96D479.88CED573@cisco.com> Date: Tue, 19 Mar 2002 01:02:33 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'sip@ietf.org'" Subject: Re: [Sip] comments on privacy-04 References: <70565611B164D511957A001083FCDD5601870176@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jon Thanks for the comments. I've responded below, however if possible, I would suggest breaking this into a couple of threads. "Peterson, Jon" wrote: > Since we now have a WGLC on sip-privacy-04, I have a couple of comments that > I apologize in advance for not presenting earlier. > > I think that SIP needs a network-provided privacy mechanism, and I think the > system described by this draft is a reasonable solution to that problem. > However, the sip-privacy-04 system is more complicated than it needs to be > in order to solve this problem, and these complexities give rise to > confusions about the implementation and applicability of the mechanism. > Today, the SIP charter speaks to a need for privacy mechanisms but not, for > example, for new identity-assertion mechanisms. > > Jon Peterson > NeuStar, Inc. > > ----- > > - rpi-screen: As the recent thread in the SIP ML suggested, the behavior in > sip-privacy-04 for handling RPIDs received from an untrusted source might be > confusing. If untrusted entities shouldn't add the RPID header (which I > gather from the applicability), then why not say that a proxy MUST remove > any RPID headers it receives from an untrusted source? Today, it sets the > 'screen=no' parameter instead. However, no behavior in the document is > defined for using an RPID header with 'screen=no' - it merely says that a UA > that receives it in a message shouldn't trust it (although what exact > behavior this entails is unclear). I may choose to display the information but with an indication that it is untrusted. For example, if I'm busy and I get a call claiming to be from my wife with a "screen=no" indication, I'll probably take the call. However, if I get a call claiming to be from Elvis Presley with a "screen=no" indication, I probably won't. > If this is totally deadweight in > signaling, it should just be removed - SIP messages don't need any help > getting larger. If you receive a RPID from a trusted entity, 'screen=yes' > could just be assumed; a parameter that says "trust me" may very well be > redundant in a trusted network. If it turns out that an RPID that the proxy > will add itself is identical to an RPID that has been supplied by an > untrusted source, then while this may be just lip service I think the least > ambiguous and most secure language is still to say that the proxy removes > the untrusted header and adds a trusted header. Just because a given piece of identity information could not be verified, does not mean it is worthless and hence I would not want the proxy to try and get "too smart" here on my behalf. I prefer deciding myself whether I want to use the information or not - all I need to know is whether I can trust it or not. Thus, I would not want to mandate removal of Remote-Party-Id headers that cannot be verified. > If for whatever reason it > turns out we do need this parameter, the idea that both 'screen=yes' and > 'screen=no' can appear in the same RPID header (this is permitted in 6.1) > must be unnecessary. It's not permitted, however should you receive this, then "be liberal in what you accept". > Finally, if you are going to have this parameter, > calling it "screen" is a little misleading; screening in the PSTN can refer > to selectively blocking calls based on the original calling/called number > (to me it implies that some feature has been invoked that inspects the ANI > and the dialed number and determines that this is a legitimate target for > the caller's class of service). Maybe "verify" would make more sense. On the other hand, both SS7 and Q.931 define a screening indicator similar to the function in the privacy draft, so I think this is OK as is. > - rpi-pty-type: This parameter allows you to specify which party's identity > is contained in the RPID header ("calling" or "called" are currently > allowed). However, no motivation for this capability is presented in the > draft - it defines the conditions under which these parameters are inserted, > but there is no recipient behavior that justifies their insertion. Moreover, > the behavior for adding the parameter holds only that a request contains a > 'calling' id, and the response contains a 'called' id. This sounds right - > I'd imagine that a privacy mechanism would use the RPID header to express > the private identity of the sender of a message; and in fact, if the > rpi-id-type header is not present, that's exactly what the recipient > assumes. So in short the motivation for this parameter isn't clear. If there > is a need for it then the draft should describe it, otherwise, I think this > parameter should be removed, since the default behavior seems appropriate. It's a question of generality (actually two) 1. Do we foresee a need for having calling and called in other messages than respectively requests and responses ? I believe Dean had a 3GPP example from Germany where this was needed. 2. Do we want to enable other party types in the future ? This is a question of extensibility. > > This draft allows network-asserted identity as a means to end-user privacy; > the identity that is private is the identity of the originator of the > message. Finally, if you are going to have this parameter anyway, "calling" > and "called" are a little too telephony-specific, and those telephony roles > don't map cleanly onto the mechanism. This is already causing problems in > the draft: in 7.5, it suggests that you proxies should use the "calling" > rpi-id-type to identify the originator of any INVITE request - but what > about a re-INVITE in the reverse direction in the middle of a dialog? I agree the terms "calling" and "called" are somewhat misleading at this point. Let me know if you have better suggestions. > > - rpi-id-type: I find this the most problematic of the existing parameters. > I believe that the sip-privacy mechanism (at least, this chartered work) > exists to make an identity private, not to invent new forms of identity. I > believe that the kinds of entities in a SIP network that have privacy > concerns are users - not client devices, or intermediary devices, or what > have you. Now, that isn't to say that keeping a user's identity private > might not require hiding information about the device from which a user is > calling, and so on. This does not, however, motivate a need for a > network-asserted device URI like the "term" value of the rpi-id-type. No > proxy or UAS behavior is suggested in the document for use of the "term" > rpi-id-type, nor is it made clear how a proxy inserting this RPID would know > to assert an "identity" for a terminal (possibly from some out-of-band > authentication mechanism? but does the terminal authenticate itself as well > as the user?). How you determine identity of any type is outside the scope of the document. As to "terminal" identity type, I could imagine a service where calls originated from some devices would get a different treatment than calls from other devices, irrespective of the user making a call. I will grant you that it's not clear why the remote party would want to know the terminal identity, but I can see uses for this at intermediaries as well as the ability to actually suppress my terminal identity. > Also, the distinction between "user" and "subscriber" in > privacy-04 is a little confusing. They represent a new distinction between > identities in SIP, and it isn't particularly clear why they are required as > part of a privacy mechanism; the difference between a "subscriber" (the > default, and traditionally the user of the SIP session), and a "user" seems > to be somehow related to settlement, or the administrative grouping of user > accounts. It isn't clear how a proxy would ascertain that it needs to apply > these parameters to an RPID, or how they'd be used True - this would be part of the authentication framework which is outside the scope of the document. > So, I'd also like to > suggest that if there is a need for a parameter or header that can assert > arbitrary new types of identity (distinguishing between subscribers or > users, URIs for devices, secret superhero identities, etc), then I for one > would like to see this proposed in a separate document. New types of > identity introduced to SIP may in turn have some privacy requirements, but > it does not follow from this that a privacy document is the right place to > propose all kinds of new identities. If these identities are useful outside > the context of privacy, that might have suggested that this is a separable > issue. The privacy considerations for these new identities can be explored > subsequent to their acceptance by the SIP community. I'm not sure how to answer this except that the three types of party identity very specifically requested to be in the privacy draft and they have been there for a loong time without anybody complaining. > For the time being, I > think this parameter is superfluous and confusing, and it should be removed. > > - rpi-privacy: To me this parameter is really the crux of the draft - that > and the fact that the RPID header can be added, deleted or modified only by > proxy servers. Not quite - trusted UA's add it too. > However, it hasn't been clear to me why the privacy parameter > is defined only within the scope of the RPID header. If we would like this > draft to have general applicability to the privacy problem, perhaps it would > be better if "privacy" were defined as a general URI header. This is an interesting idea, albeit perhaps a little late. I presume you would then require that any header containing a URI with a privacy indication would have to have privacy afforded to it as described for Remote-Party-Id in the current draft ? > The RPID header > should usually, but perhaps not always, contain a URI that has a "privacy" > parameter. I'd be interested to hear if there are scenarios within the > applicability of the draft in which the RPID header should be used without a > "privacy" parameter - perhaps the presence of "privacy" in RPID could be a > MUST. There should only be a privacy parameter if the user has asked for privacy (or if he specifically does not want privacy). Omitting the privacy parameter is thus perfectly reasonable and in fact quite common I suspect. > However, I see no reason why it might not make sense for other URIs > than those in an RPID to contain the "privacy" parameter. > This is a good point indeed, but it would be a significant change. I would like to solicit more input on this. > > - Extensibility: While it's generally desirable for a mechanism to be > extensible (you should reuse existing mechanisms to solve new problems if > you can), sometimes extensibility can be confusing. Given the strict > applicability that precedes sip-privacy-04, it isn't really clear how much > extensibility is desirable - and at what point extensibility would invite > the use of RPID to architectures outside of that applicability. While I > applaud the move in sip-privacy-04 to require that extensions to the RPID be > published in an RFC, I'm not sure that this alone is sufficient. The middle > two parameters I've discussed above (rpi-ip-type and rpi-pty-type) are > extensible in privacy-04. Given that I'm a little queasy on their current > values (not to mention their overall relevance), it would probably go > without saying that I'm unsure about extending them further. These > reservations do not however carry over to the 'rpi-privacy' parameter - I > believe that should be extensible. This is largely a philosophical discussion. I personally feel (and I know I'm not the only one) that the extensibility is important as it allows you to reuse the general privacy handling defined in the draft. However, I also understand the concern you have about misuse of this extensibility which could turn Remote-Party-Id into something it was not supposed to be. I believe that requiring such extensions to be documented in an RFC and also to have a designated expert review the extension is a good compromise towards satisfying the desires and concerns of both sides here. > > - RPID-Privacy: The need to assert any of the above parameters in the > RPID-Privacy should probably also be revisited in the light of the > considerations above. I think it's pretty clear that an RPID-Privacy header > should express the wishes of the originating user to keep their identity > private in this message, and it isn't clear why a user would want to tell > the network to, say, keep some other user's identity private. If this is > needed, the draft should explain when it would be useful. > I think the resolution here should be the same as for the Remote-Party-Id header itself. > > - Gobbledygook in From: The motivation for cryptographically random garbage > in the From header may have gone away in light of the mandate for the 'tag' > parameter in the From field of requests in rfc2543bis, which guarantees that > dialog identification will be globally unique. I would suggest instead that > the From header for an anonymous request should be completely homogenous, so > all private From headers look alike. rfc2543bis09 actually contains examples > of both - in some places, anonymous requests use an apparently random user > and/or host, in other places something standard like 'anonymous@localhost'. > I would recommend the latter, if only because you already have to build > something globally unique for the tag I agree. -- Flemming > - or at the very least, that this > point be revisited in light of bis. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 10:27:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24291 for ; Tue, 19 Mar 2002 10:27:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA23150 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 10:27:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22121; Tue, 19 Mar 2002 10:09:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20850 for ; Tue, 19 Mar 2002 09:58:09 -0500 (EST) Received: from hotsip.com ([212.28.214.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23512 for ; Tue, 19 Mar 2002 09:58:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Mar 2002 15:57:35 +0100 Message-ID: Thread-Topic: Supported compact form gone? Thread-Index: AcHPVplXHW+QfCjXTeSxu2ezAeTlbw== From: "Christian Jansson" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA20851 Subject: [Sip] Supported compact form gone? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Is the Supported header supposed to not have any compact form anymore, or is it just a typo? BTW, wouldn't the world be better without compact forms at all... ---------------------- Christian Jansson Hotsip AB Barnhusgatan 16 111 23 Stockholm Tel: 08 454 05 04 Mobil: 0739 888 163 ---------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 11:00:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25159 for ; Tue, 19 Mar 2002 11:00:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25730 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 11:00:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23826; Tue, 19 Mar 2002 10:32:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23792 for ; Tue, 19 Mar 2002 10:31:56 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24400 for ; Tue, 19 Mar 2002 10:31:52 -0500 (EST) Received: from BobP (BobP.ietf53.cw.net [166.63.181.181]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 0D3596A90E for ; Tue, 19 Mar 2002 09:31:53 -0600 (CST) Message-ID: <002b01c1cf5a$f928ee20$b5b53fa6@acmepacket.com> From: "Bob Penfield" To: Date: Tue, 19 Mar 2002 10:30:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] update-01: the 155 response and implied errors Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Last night at the meeting I raised the issue that it is burdensome for the UAC to figure out what the problem is with a request when a 155 provisional response is received. For example, there would be no way to tell that a 416 (Unsupported URI scheme) problem exists. There were 2 suggestions to solve this problem. 1. Include the proposed Reason header (or a simple version of it) which would indicate the associated 4xx error code. 2. Include a status-line in a sipfrag body. The first option was rejected because the Reason header will not be ready in time for the 2nd bundle (manyfolks, privacy, call-auth, etc.) and it has also been sent back to SIPPING for a better definition of requirements. The idea of a simplified reason header was rejected because we don't want to add too many headers. The second option does not seem promising because of issues raised with the sipfrag MIME type (I'm not aware of what those are). My fear is that we would need a new option tag when the Reason header was done because it would impose slightly different behavior requirements on the UAS and UAC. After further investigation, it appears that only 416 is a problem and all other reason can be determined by the presence of a specific header (as described in the draft). Therefore, if we just added another status code (say 156) to cover 416, I think we would have everything covered. 401: 155 with WWW-Authenticate 407: 155 with Proxy-Authenticate 415: 155 with Accept/Accept-Encoding/Accept-Language 416: 156 420: 155 with Unsupported 423: 155 with Min-Expires 488: 155 with Warning This still requires the UAC to check the headers. And presence of an Accept header does not necessarily imply 415, unless we change the draft to say that it does. We could specify that all the other headers should be checked first. Another alternative would be to define a 15x status codes for each corresponding 4xx code so that the UAS can be explicit about the problem. 401&407: 151 415: 152 416: 153 420: 154 423: 155 488: 156 We could use 150 as a place holder for use with the future Reason header and indicate that the UAC should CANCEL if it cannot figure out what the problem is. The new status codes may be overkill. Thoughts? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 11:04:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25303 for ; Tue, 19 Mar 2002 11:04:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26129 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 11:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24138; Tue, 19 Mar 2002 10:37:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24063 for ; Tue, 19 Mar 2002 10:37:15 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24583; Tue, 19 Mar 2002 10:37:12 -0500 (EST) Received: from eburger (eburger.ietf53.cw.net [166.63.183.156]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 937CB6A919; Tue, 19 Mar 2002 09:37:14 -0600 (CST) Reply-To: From: "Eric Burger" To: "Gonzalo Camarillo" Cc: "SIP List" , "Sipping" Subject: RE: [Sip] Requirements on Reason information. New I-D Date: Tue, 19 Mar 2002 10:36:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C96F057.6AE2D67@lmf.ericsson.se> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is why we have SIPPING: the REASON header would be a sensible way of solving the issues raised by Gonzalo in his draft. In addition, it would, with some modifications, also solve the issues raised in draft-watson-sipping-req-history-00.txt. I would propose that the requirements raised in draft-camarillo-sipping-reason-00.txt get folded into a revision of draft-watson-sipping-req-history. Correct me if I'm wrong, but I don't think draft-schulzrinne-sip-reason-01.txt, as it stands today, addresses the history part of the SIPPING requirements. The draft is silent on this point, but it looks like the SIP entity generating the message with the Reason header inserts it only for *its* operation. That is, it explains why that particular entity failed. Said differently, it looks to me that there will be only one Reason header in a SIP message. If we can carry and identify the source of the Reason headers, like we do for Via or SMTP does for Received-By, then this header can satisfy both camarillo-sipping-reason's and watson-sipping-req-history's requirements. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Gonzalo Camarillo Sent: Tuesday, March 19, 2002 3:01 AM To: sip; Brian Rosenberg (EUS); Dean Willis; Joerg Ott; rohan@cisco.com Cc: Henning Schulzrinne; oran@cisco.com Subject: [Sip] Requirements on Reason information. New I-D Chairmen, I presented the Reason header field draft today in the SIP WG meeting: http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-01.txt Some folks considered that the requirements for this work were not clear enough, so I was asked by the chairmen to write a set of requirements. We agreed that there was no need to wait for the next IETF meeting in order to progress such a requirements draft. Discussions in the mailing list were encouraged. I have put together an I-D with those requirements. http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt I would like to know if these requirements are what you expected or if, on the other hand, you wanted something else... I intend to submit this draft, including the comments I may receive, on Monday. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 11:14:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25660 for ; Tue, 19 Mar 2002 11:14:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26911 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 11:14:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24950; Tue, 19 Mar 2002 10:54:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24919 for ; Tue, 19 Mar 2002 10:54:27 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24943 for ; Tue, 19 Mar 2002 10:54:24 -0500 (EST) Received: from BobP (BobP.ietf53.cw.net [166.63.181.181]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 8AE316A90E; Tue, 19 Mar 2002 09:54:27 -0600 (CST) Message-ID: <006101c1cf5e$207ca680$b5b53fa6@acmepacket.com> From: "Bob Penfield" To: Cc: "Jonathan Rosenberg" Date: Tue, 19 Mar 2002 10:52:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] update-01 comments Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 4 says the UPDATE may contain an offer any time after a dialog is established. Although section 5.3 says it must follow the offer/answer rules you may want to point out in section 4 that the UPDATE can only contain an offer if allowed under the offer/answer rules. Section 5.3 talks about the Supported header in the response, but section 5.2.1 mandates the response contain the Require header. This should be made consistent. Otherwise it is not clear why the Require:update is needed. Also, the language in 5.3 implies that the fact that it is a 155 response is sufficient. Since we have changed the strength of the UAS requirement for generating a 155 from MAY to SHOULD, I suggest that we change the addition of Require:update in the proxy from a SHOULD to a MAY. If the UAS does not support update, you'll end up with 3 exchanges if there is a repairable error in the INVITE instead of 2. I don't see any great advantage in the proxy requiring update. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 11:50:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26744 for ; Tue, 19 Mar 2002 11:50:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29381 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 11:50:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28020; Tue, 19 Mar 2002 11:32:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27829 for ; Tue, 19 Mar 2002 11:32:23 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26143 for ; Tue, 19 Mar 2002 11:30:29 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA15587; Tue, 19 Mar 2002 17:29:50 +0100 (MET) To: Jonathan Rosenberg , Gonzalo Camarillo Cc: sip@ietf.org Date: Tue, 19 Mar 2002 17:29:47 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/19/2002 17:29:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Sip] Offer by the callee Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I'm trying to connect the offer/answer, update and manyfolks drafts for the following scenario: - Alice sends an INVITE to Bob with "offer-1" - Bob wants to make an "offer-2" to Alice, before the completion of the session establishment - Bob would like to ask Alice to start resource reservation only based on the acceptation of "offer-2", and not before (in fact Bob knows that it is useless to start resource reservation based on offer-1, because he knows he will send immediatly a new offer-2, but he is obliged to wait for Prack before) The Update draft defines the response 155 to allow the answerer (the callee in our case) to request "Mr. the calling, please *send me* a new offer", but there is no way for the same callee to announce "Mr. the calling, *I want to send you* a new offer right now". So, one possible way to achieve that is that the callee sends an answer to the original offer but disabling all the media (in order to avoid to start resource reservation), and next proposing a new offer, as described in the call flow below (assume for the example that they are using end-to-end resource reservation, but please don't generate a new debate on this topic): Alice Bob INVITE (offer-1) -----------------------------------------------------------------> 183 (answer-to-offer-1, all port numbers to zero) <----------------------------------------------------------------- PRACK -----------------------------------------------------------------> 200 PRACK <----------------------------------------------------------------- UPDATE (offer-2, status-type=e2e) <----------------------------------------------------------------- 200 UPDATE (answer-to-offer-2) -----------------------------------------------------------------> <========== Resource Reservation ==========> UPDATE (current-status = desired-status) -----------------------------------------------------------------> 200 UPDATE <----------------------------------------------------------------- 200 INVITE <----------------------------------------------------------------- ACK -----------------------------------------------------------------> Is this scenario compliant with the drafts Offer/Answer, Update and Manyfolks ? Thank you for your answer Best regards Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 13:37:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29980 for ; Tue, 19 Mar 2002 13:37:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07781 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 13:37:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06766; Tue, 19 Mar 2002 13:18:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06674 for ; Tue, 19 Mar 2002 13:18:02 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29542 for ; Tue, 19 Mar 2002 13:17:10 -0500 (EST) Received: from BobP (BobP.ietf53.cw.net [166.63.181.181]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 8D4B86A91C; Tue, 19 Mar 2002 12:17:06 -0600 (CST) Message-ID: <001a01c1cf72$0e5d4720$b5b53fa6@acmepacket.com> From: "Bob Penfield" To: Cc: "Jonathan Rosenberg" References: <006101c1cf5e$207ca680$b5b53fa6@acmepacket.com> Subject: Re: [Sip] update-01 comments Date: Tue, 19 Mar 2002 13:15:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit One more comment. This may have already been covered by other comments, but I could not find a requirement that the UAC MUST receive the 200 OK to the PRACK for the 155 response before sending an UPDATE. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 14:52:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02179 for ; Tue, 19 Mar 2002 14:52:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12878 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 14:52:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12335; Tue, 19 Mar 2002 14:41:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12273 for ; Tue, 19 Mar 2002 14:41:26 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01765 for ; Tue, 19 Mar 2002 14:41:23 -0500 (EST) Received: from BobP (BobP.ietf53.cw.net [166.63.181.181]) by noc-e.ietf53.cw.net (Postfix) with SMTP id 6522F6A91E for ; Tue, 19 Mar 2002 13:41:23 -0600 (CST) Message-ID: <378401c1cf7d$d456bb40$b5b53fa6@acmepacket.com> From: "Bob Penfield" To: Date: Tue, 19 Mar 2002 14:39:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on sip-auth Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have two comments on the sip-auth draft. I apologize if these issues have already been raised. Has the idea of qop value for authentication plus header integrity without including the message body been considered? In situations where the request must traverse a NATing SIP element which "fixes" the IP addresses and ports in the SDP to enable the RTP media flows, the only alternative is plain "auth" and no integrity at all. Section 7.3 says: If a stateful proxy receives a 492 and determines that it contains a single UAS-Authenticate header targeted solely at itself, it MAY resubmit the request to the UAS with a UAS-Authorization header containing the credential as a separate branch. I don't think this is possible because the Cseq number must be increased (otherwise it will look like a re-transmission or merged request) and the proxy does not own the CSeq. It would have to be a B2BUA and generate its own Cseq (and possibly Call-Id). cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 15:10:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02584 for ; Tue, 19 Mar 2002 15:10:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14071 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 15:10:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13128; Tue, 19 Mar 2002 14:57:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13091 for ; Tue, 19 Mar 2002 14:56:59 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02260 for ; Tue, 19 Mar 2002 14:56:55 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2JJuQe10577 for ; Tue, 19 Mar 2002 13:56:27 -0600 From: "Dean Willis" To: Date: Tue, 19 Mar 2002 13:56:23 -0600 Message-ID: <003801c1cf80$25db7f30$b3bf3fa6@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Notes, SIP Session 1 from Vijay Gurbani Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit HTML posted at http://www.softarmor.com/sipwg/meets/ietf53/notes/notes-sipwg-session-1- ietff53-gurbani.html Notes, SIP WG, Session 1, IETF 54 ------------------------------------------------------------------------ -------- Reported by Vijay Gurbani, vkg@{lucent.com,research.bell-labs.com,acm.org}, edited slighty by Dean Willis ------------------------------------------------------------------------ -------- 19:30 CST meeting started 19:33 Agenda accepted Work Plan update: * We have revised the SIP spec; went to IESG; resulted in a "Yea" from IESG. SIP events spec is done. * Session timer is back to haunt us -- goes back to authors for bis update. * Caller pref - pending from author for bis. * Precondition extensions -- in WGLC now; in IESG by April SIP * Privacy spec from DCS in WGLC now, IESG by April * REFER Method; needs bis, security updates. IESG by May? No complaints from authors. More important since there are many implementations already. * MESSAGE method ready for WG LC -- have not done it yet. * PATH method needs rev from editor. Call for volunteers. * NAT awareness: rev pending from author. * SIP Privacy and Security reqs to IESG? There is a feeling that the SIP extensions for privacy wrt to 3GPP is not acheivable -- Jon P: some privacy (user provided privacy vs. network provided privacy) nuances have not been captured as of today. Henning: that would make a lot of sense if we know what we wanted -- another req document is not in and of itself useful. Dean: SIP privacy and security reqs predate the SIPPING WG -- IESG felt that it is such a critical piece that it should stay in SIP WG. * SIP over SCTP? Gonzalo: we are ready for WG LC for SIP/SCTP. Dean: Also in July timeframe -- have a draft standard version of SIP -- #1 goal in July of 2003. Original SIP spec was 2543, we want to claim new number of 3543 :-) * State: Charter item of pushing certain things off the SIP signaling state -- state or cookies specification translated to SIP. Did we ever come to a consesnus on how to go forward? Rohan: Cookies I-D is good for doing what you want to do with the state I-D and is more general. I support it. Dean: Anyone know of implementations? [No implementations yet] Jonathan Rosenberg: The reason noone has implemented it is because everyone is using R-R and Contact. It is not entirely clear to me that this is even needed. Fleming: The difference is that R-R requires the proxy to be in all signaling. Andrew Zmolek: We looked at R-R issue and it seemed that we were going to have some trouble -- either the state or the cookies would do fine JDR: R-R was not sufficient since there was no reliable way to put something and get it back. With the new R-R update, this is no longer an issue. rjsparks: You cannot change the state in a dialog, you can only push and get the state. JDR: Okay, if that is the requirement, then fine -- if the req is to just push state for the purpose of a dialog, we have a mechanism already in R-R, Contact. Brian Rosen: we may work on a requirement document offline, assuming that it is useful. * General Scheduling: Henning: meta scheduling aspect -- can you get people involoved long enough to remember what the issue was? Brian: Our goal is to get a lot of stuff out that has been hanging around for a long time -- but we do not want to get out 12 LC I-Ds at the same time. We will revive the LC schedule we had going. Henning: Do other I-Ds that are not on your list wait until re- chartering? Brian: No. There are some things that are hanging around for a long time; as long as the ADs do not breath down on us, we will work on them as we go along. Henning: Need a priority list. Jonathan: Learn from successes -- Bundle 1 was a success delivery to 3GPP. With the current mechanism we were randomly LC'ing. One of the thing the Bundle did is to focus people's energy on that. Brian: We can consider that; Bundle 1's advantage was that the drafts were related to one another. These do not. * What do we do with: sipping-conferencing-models? sip-3pcc? app-componente? sip-vxml? Jonathan: need to finish bis update; but done as far as I know. Rohan: 3PCC is a very pure usage draft describing the usage of baseline bis offer answer model. Most of the stuff above is usage or framework, we should get it done in SIPPING. Brian Rosen: You are basically saying what Jonathan said: Put it in Bundles. Rohan: Sure. SIP Change process, Allison Mankin: This is not a SIP draft; it is an individual transport area draft. People have said that there is no need to control SIP information. The Replaces header was done in a freeform manner -- this is not good. WG discipline needed over extensions of SIP. RFC 3261 (new bis) has an IANA consideration which is very different then what you have seen before. You need a standards track RFC for headers, method, response codes, warning codes. One place you do not need to do this is for the Events RFC -- just need WG yes for these. serverfeatures did not go too far with IESG since it offered unbridled extensions. We now have P-header (not X-header, more constrained). Still need a RFC, but you do not have to have the buy in of SIPPING or SIP. The string with P- is reserved if they are to have a future life. Henning: while I agree with the notion, the naming has the same problems that X headers had. Attaching a meaning to "P-" is not good. Allison: They do not have option tags and have to have applicability statements. Henning: There are 2 issues: naming and process/applicability. If we have a header name which was registered (say, foo); that header has the property that as long as it is in the non-RFC track, it looks like a normal header. If it reaches standards track, it retains its name. Lets say P-bar header becomes popular and widely implemented. Now, if P-bar header goes to standards track, they will have to rename this header. Allison: can you make a P-header a standards track header -- add an option tag. Dean: The P- name will still be registered and be useful. Now you will basically have to track P- and non-P extension headers -- makes the symbol table little large -- that's okay. Dave Oran: feel uncomfortable in mixing naming conventions and algorithimic behavior. I do not like the idea of having to parse inside header string. Jonathan Rosenberg: The name of the option tag is unrelated to the name of the header. Henning: HTTP extension model is different then SIP extension model. There is no correlation in header names and option tags. Allison: If the I-D has any implications of this sort, we can fix it. Gonzalo: We have option tags that have no headers associated with them. Keith Drage: We need to make sure that this I-D does not contain any requirements on SIP implementation -- a SIP implementor must not have to read this I-D. The UPDATE method - Jonathan Rosenberg : Open issues 1) Glare with PRACK - UPDATE only specifies glare resolution with itself. You can have glare with PRACK. Rejecting PRACK is bad. Solution: can't send UPDATE if you have sent an answer in 18x for which you have not gotten a PRACK. Will put some words with general caveats. 2) Repairable response codes -- automata can fix these without human intervention. What about 493 Undecipherable? May require user intervention to fix it. Proposal: include it, add text saying it retries if it would otherwise retry with that response. [No one objected]. 3) Generate 155 instead of 4xx MAY or SHOULD -- for backward compatibility. SHOULD is better if the UAS supports this capability, the proxy may not. This makes it work at proxies transparently. Comment: This text is screaming for a reason header, otherwise the UAC will have to infer what the problem is. JDR: I did not talk about reason header for a reason -- it is on a slower track. For the basic cases we are worried about immiedately, the UAC can infer from the headers. Going forward, the reason header is the way to go. Gonzalo: The last review of the reason header already has this, so we can use it. Jonathan: Does the group agree that the message sip (or sip frag) is the appropriate approach? Or wait for the reason header (which is on a slower track). Rohan: Can we pull out 155 out of this, then? [No consensus on this] Manyfolks open issues (Gonzalo Camarillo) draft-ietf-sip-manyfolks...-05.txt We are now defining a framework for preconditions of different types. We define the current status of the precond vs. desired status. We always know if current status is better or worse then desired status. Two status types: e2e -- always present in manyfolks (-04). Segmented status type introduced in -04. Open issues: Meaning of Require: precondition -- 2 appraoches: I refuse everything I don't understand. Or be liberal and accept the offer if the preconditions can be met without your intervention? Which is better? 1 or 2? Comment: you can have a thing called "criticality" which gives a hint on what to do. Gonzalo: I will decide after speaking to Mark. Reason code, Gonzalo Camarillo.: Requirements: same functionality needed in several WG items -- why is this request (or response) being sent? Useful in many works: ISUP/SIP mapping, in manyfolks (precondition failure, unacceptable here), HERFP, 3pcc. Jonathan: Throw in another use: in the event that you fork the request to a bunch of phones and one of them picks up. The proxy generates CANCEL. The reason for CANCEL is not because the user hung up, but because 1 of N answered. Rohan: Lot of overlap in the reqs that generated this document and request history. Eric Burger: This is H.450 all over again. Jonathan R: Don't we have an enumerated list of response code in the bis already? This is exactly that, and then some. Comment: we have one address space for responses, and we have just added one more with the Reason header. Has a kitchen-sink feeling to it. Henning: The motivation was exactly to prevent reinventing the same thing everytime. We are not adding new error classes that will have to be percolated to all existing implementation. This is a fine grained status code which is there if you need it. Example: Q.850 error code will not be pertinent to many implementations, but to the one that it is pertinent to, it can use it without too much perturbation. Brian Rosen: What do we do now? 2 possibilities: crisp set of reqs, which are clear and this is a resonable solution. Or we do not have a crisp set of reqs. We need to determine this first. Lot of discussion on if this does or does not solve the job. But do we know what the job is? Should we push this back into sipping and generate a req document? Those who think we have a sensible set of reqs and we can move forward? Those who need more reqs? [The hum level was 50-50, no consensus by humming on if we have the reqs captured right.] Dave Oran: Need hum on slightly different -- do we get involved in reqs that requires identity (being able to communicate why you are sending it to this particular party). Brian Rosen: That is a reasonable suggestion -- so considered. We will get the reqs out before Yokohama and bring the solution out before then. Those of you who hummed against it should participate in the list when we discuss this on it. Fleming Andreson, SIP Extensions for Media Authorization. draft-ietf-sip-call-auth-04.txt : Changes: Category is informational -- Header is now P-Media-Authorization. Applicability statement about appropriate use (SIP Proxy and Policy Server (PDP) must belong to the same domain) Updated rules about when to add a P-Media-Authorization header. Additional security considerations -- don't encrypt message bodies (proxies need to examine them). Open issues: None known (authors list need to be trimmed), currently in WGLC. Jonathan: I will send you some minor reviews. More look-see needed in the security section. This token is about media authorization -- authorization follows authentication. DOes the I-D point out this issue? Fleming: You do not neccessarily need to authenticate before authorization. Some entity has been given an authorization token to access some resource. Jonathan: More discussion maybe needed on the security section -- you are giving a token to a party that you may not have authenticated. If that is your model, fine; a couple of sentences would probably suffice in the I-D. Brian Rosen: The WGLC is going to get over, if anyone wants to raise more issues please do so. It fills the needs, even though it has a lot of limits. LC be it, we will move forward. Ben Campbell, SIP Extensions for IM : -05 draft; recent changes -- remove CPIM mapping to separate draft. Would like to include in 3rd bundle to IESG. Highlights - sends IM; does not initiate a dialog, does not discuss message sessions; actual message in bodies. Open issues: No recent discussions. Needs minor editorial changes (forking, threading -- couple of sentences). Anything else? Is it ready for LC? One more revision -- no change in substance, more editorial. Brian Rosen: Ok, as soon as you have the revision, we will post it as LC. Brian Rosen: Administering this list is no fun -- people forward their email to accounts that consistently run over quota. The list is setup so that only subscribers can post. 21:29 CST - WG adjourned. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 15:46:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03465 for ; Tue, 19 Mar 2002 15:46:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16059 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 15:46:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15651; Tue, 19 Mar 2002 15:35:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15606 for ; Tue, 19 Mar 2002 15:35:04 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03164 for ; Tue, 19 Mar 2002 15:35:01 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2JKYP315547; Tue, 19 Mar 2002 12:34:25 -0800 (PST) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACR24647; Tue, 19 Mar 2002 12:34:32 -0800 (PST) Date: Tue, 19 Mar 2002 12:32:16 -0800 (Pacific Standard Time) From: Rohan Mahy To: gonzalo.camarillo@ericsson.com cc: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Reason header simplification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, It occurred to me that there is a lot of overlap between the 1-9 reason codes in the reason header, and the 3 digit SIP reason codes. I think these could be consolidated as described below. Reason: 1 (call completed elsewhere) in a CANCEL could instead become a CANCEL with a Reason: 200 OK (you are receiving a CANCEL because the status of the call was a 200 OK, presumably from another branch). The only difference between Reason 2 (abandoned) and Reason 4 (terminated) is that 2 is used in CANCEL, and 4 is used for BYE. We could allocate a new 4xx response code (say 499) for "terminated" and use this instead. This response code would also be useful in the call-info package. Reason: 3 (timed out) is easily expressed with Reason: 408 Timeout Reason: 5 (transfer complete) isn't needed because a notification to that effect is generated when using REFER Reason: 6 (no media) could be represented with a new response code (say 498) Reason: 7 (interworking) does really have any semantic meaning, so just use the SIP response code. Reason: 8 (offer refused) sounds like a 603 Decline or 488 Incompatible Media to me. The SIP responses are actually more rich, but not significantly more complex. Reason: 9 (update requested) can be implied by the fact that the reason header is in a 155 response. the "real" reason is the repairable error Also I don't like to idea of sending ISUP (Q.850) or ISDN (Q.931) response codes around inside a SIP network. I'd rather use standard ISUP-SIP or ISDN-SIP cause code translation, so that an ordinary SIP UA can just use a set of well-defined SIP cause codes. hope this makes sense. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:01:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05514 for ; Tue, 19 Mar 2002 17:01:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA20659 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:01:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19281; Tue, 19 Mar 2002 16:49:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19249 for ; Tue, 19 Mar 2002 16:49:40 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05134 for ; Tue, 19 Mar 2002 16:49:34 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Mar 2002 21:49:55 UT Received: from jolaptop ([166.63.182.123]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 19 Mar 2002 21:52:52 +0000 From: "Jo Hornsby" To: "Bob Penfield" , Subject: Resubmitted Requests that might not Merge (Was: [Sip] comments on sip-auth) Date: Tue, 19 Mar 2002 21:56:20 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <378401c1cf7d$d456bb40$b5b53fa6@acmepacket.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 19 Mar 2002 21:52:52.0264 (UTC) FILETIME=[6B20DA80:01C1CF90] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Section 7.3 says: > If a stateful proxy receives a 492 and determines that it contains a > single UAS-Authenticate header targeted solely at itself, it MAY > resubmit the request to the UAS with a UAS-Authorization header > containing the credential as a separate branch. > > I don't think this is possible because the Cseq number must > be increased (otherwise it will look like a re-transmission > or merged request) and the proxy does not own the CSeq. It > would have to be a B2BUA and generate its own Cseq (and > possibly Call-Id). Actually, I think this may be fine. Section 8.2.2.2 of RFC3261^H^H^H^H^H^H^Hbis-09 only puts a SHOULD strength on a 482, and thus I see no reason for clever UAs to not look out for resubmitted requests (i.e., those that are only different based on the topmost-Via), such that they can attempt to resatisfy the request based on the condition that the previous N-instances of this request were all treated to a non-2xx final. I thought that there had been some mention of this in Session Timer (because there are cases where a UAS can receive a request N times; along (N - 1) paths the refresh interval is too small, but along one path, it is acceptable; if the acceptable path "arrives" last, not treating it as a merge avoids RTTs in negotiation, which may not even occur if UPDATE is not supported). But a quick skim failed to turn anything up. However, there was definitely a mailing- list thread that ultimately produced the new merge behaviour. Furthermore, a similar approach is suggested in update-01 Section 7, when a proxy does the Require:update thing. Now, I expect this to become less common, based on the proposed resolution of a UAS sending a 155 being SHOULD; however, it does seem to me that it would be a shame to rule it out, since I can see very little that's -ve about it beyond a slight bit of extra logic in the "UAS core". - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:21:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06152 for ; Tue, 19 Mar 2002 17:21:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21928 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:21:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21069; Tue, 19 Mar 2002 17:07:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21043 for ; Tue, 19 Mar 2002 17:07:12 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05637 for ; Tue, 19 Mar 2002 17:07:03 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 14:07:02 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Date: Tue, 19 Mar 2002 14:07:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] SIP Change Process Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I believe that the SIP Change Process should be relaxed to allow non-chartered SIP extensions to define SIP option tags for use in Supported but but not in Require. Unless the aim of this draft is to prevent any non-chartered work from doing anything useful, this is an important distinction. I also see the current restriction (no option tags whatsoever) as actually counter-productive to the future state of the protocol - it simply forces authors to generate additional P-headers to indicate the ability to support an uncharter extension. Take as an example a typical P- compliant service such as media authorization. An entity may desire to know whther an access network supports media authorization before blindly placing a call with the P- media authorization header. Forcing networks to statically configure this knowledge is not desirable. Forcing authors to invent separate P- headers to indicate support for media authorization is not desirable. [I merely use this as an example; I am not saying that this needs to be added to that particular draft.] Another argument: If someone writes a "P-Supported" extension draft then I beleive that this extension exactly falls into the restrictions of the SIP Change Process itself. The Supported header merely provides transparent information - exactly what P-headers were designed for. Thus, there should not be a restriction on the use of option tags within the normal Supported header. Require yes, Supported no. As I said before, this eases migration of unchartered work group items into chartered items, that is, authors do not need to invent specific P-header mechanisms to cover the inability to use the normal Supported header. That's my two cents anyway. Cheers, Robert. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:21:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06173 for ; Tue, 19 Mar 2002 17:21:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21944 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:21:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21325; Tue, 19 Mar 2002 17:12:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21294 for ; Tue, 19 Mar 2002 17:12:01 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05833 for ; Tue, 19 Mar 2002 17:11:58 -0500 (EST) Received: from eburger (eburger.ietf53.cw.net [166.63.189.43]) by noc-e.ietf53.cw.net (Postfix) with SMTP id D6C696A922; Tue, 19 Mar 2002 16:12:00 -0600 (CST) Reply-To: From: "Eric Burger" To: "Rohan Mahy" Cc: Subject: RE: [Sip] Reason header simplification Date: Tue, 19 Mar 2002 17:11:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The reason for Reason :-) is for the "extra info" that's behind the result code. Sort of an Error-Info short-hand (should it be such?). A model that this reminds me of is the VAX VMS return structure. There's the return code (which I agree with Rohan, is simply the SIP return code). Then there's the readable text. Then there's the useful info. Clearly the "useful" info is situation-specific. This is where the rest of the Reason information, *including* Q.mumble, H.foo, Unix Process Exit Value, etc. is important. The other place for Reason is to address History. The SIP result code is for *this* request. There's a need for knowing other result codes this request has been exposed to during its life. I would propose a Reason: header that is composed of the *SIP* result code (as Rohan suggests) with enriched, application-specific information (as Henning/Gonzalo suggest). -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Rohan Mahy Sent: Tuesday, March 19, 2002 3:32 PM To: gonzalo.camarillo@ericsson.com Cc: sip@ietf.org Subject: [Sip] Reason header simplification Hi, It occurred to me that there is a lot of overlap between the 1-9 reason codes in the reason header, and the 3 digit SIP reason codes. I think these could be consolidated as described below. Reason: 1 (call completed elsewhere) in a CANCEL could instead become a CANCEL with a Reason: 200 OK (you are receiving a CANCEL because the status of the call was a 200 OK, presumably from another branch). The only difference between Reason 2 (abandoned) and Reason 4 (terminated) is that 2 is used in CANCEL, and 4 is used for BYE. We could allocate a new 4xx response code (say 499) for "terminated" and use this instead. This response code would also be useful in the call-info package. Reason: 3 (timed out) is easily expressed with Reason: 408 Timeout Reason: 5 (transfer complete) isn't needed because a notification to that effect is generated when using REFER Reason: 6 (no media) could be represented with a new response code (say 498) Reason: 7 (interworking) does really have any semantic meaning, so just use the SIP response code. Reason: 8 (offer refused) sounds like a 603 Decline or 488 Incompatible Media to me. The SIP responses are actually more rich, but not significantly more complex. Reason: 9 (update requested) can be implied by the fact that the reason header is in a 155 response. the "real" reason is the repairable error Also I don't like to idea of sending ISUP (Q.850) or ISDN (Q.931) response codes around inside a SIP network. I'd rather use standard ISUP-SIP or ISDN-SIP cause code translation, so that an ordinary SIP UA can just use a set of well-defined SIP cause codes. hope this makes sense. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:41:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06636 for ; Tue, 19 Mar 2002 17:41:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23023 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:41:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22293; Tue, 19 Mar 2002 17:29:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22262 for ; Tue, 19 Mar 2002 17:29:48 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06326 for ; Tue, 19 Mar 2002 17:29:45 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2JMTla16193; Tue, 19 Mar 2002 17:29:47 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA21651; Tue, 19 Mar 2002 16:29:42 -0600 (CST) Message-ID: <3C97BBD6.46BBFB3@lucent.com> Date: Tue, 19 Mar 2002 16:29:42 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories/Lucent Technologies, Inc X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , spirits@lists.bell-lab.com Subject: Re: [Sip] Requirements on Reason information. New I-D References: <3C96F057.6AE2D67@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Chairmen, [...] > I have put together an I-D with those requirements. > > http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt > > I would like to know if these requirements are what you expected or if, > on the other hand, you wanted something else... > > I intend to submit this draft, including the comments I may receive, on > Monday. One more service that can be added in Section 5 of your I-D is SPIRITS-based services. A UA getting an INVITE may benefit from having a Reason header to make a determination if the invitation resulted from the PSTN domain. Likewise the header may help UACs that get a final response from a SIP/IN entity. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:51:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07017 for ; Tue, 19 Mar 2002 17:51:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23622 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:51:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22940; Tue, 19 Mar 2002 17:36:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22908 for ; Tue, 19 Mar 2002 17:36:53 -0500 (EST) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06513 for ; Tue, 19 Mar 2002 17:36:49 -0500 (EST) Received: from pingtel.com (Churchill.ietf53.cw.net [166.63.185.73]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g2JMd2B05121 for ; Tue, 19 Mar 2002 17:39:02 -0500 Message-ID: <3C97BCEC.E70F71E9@pingtel.com> Date: Tue, 19 Mar 2002 17:34:21 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] REFER ABNF issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I noticed two minor issues that with REFER related to the ABNF: Is there any reason that Refer-To syntax is not the following: Refer-To = ("Refer-To" | "r") ":" ( URL | name-addr | addr-spec ) There are some nice UI reasons to want to put the display name in the Refer-To field. This also makes the parsing a little more tolerant of implementions that mistakenly put the name-addr in the Refer-To field. Also should we use the absoluteURI construct as opposed to URL and reference bis for the definition as this provides a more concrete parsing syntax than is currently defined in the refer draft. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 17:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07098 for ; Tue, 19 Mar 2002 17:56:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23808 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 17:56:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23390; Tue, 19 Mar 2002 17:45:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23360 for ; Tue, 19 Mar 2002 17:45:42 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06769 for ; Tue, 19 Mar 2002 17:45:39 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA11821; Tue, 19 Mar 2002 17:45:38 -0500 (EST) Received: from cs.columbia.edu (cta.ietf53.cw.net [166.63.185.82]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2JMjWPm023886 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Mar 2002 17:45:36 -0500 (EST) Message-ID: <3C97BF73.ED97D005@cs.columbia.edu> Date: Tue, 19 Mar 2002 16:45:07 -0600 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: gonzalo.camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Reason header simplification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Also I don't like to idea of sending ISUP (Q.850) or ISDN (Q.931) response > codes around inside a SIP network. I'd rather use standard ISUP-SIP or > ISDN-SIP cause code translation, so that an ordinary SIP UA can just use a > set of well-defined SIP cause codes. > Is this translation one-to-one? Which table did you have in mind? I suspect that unless there's a one-to-one translation, you might want to include both, with the user agent displaying whatever makes sense (and leaving Q.850 codes for debugging). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 18:10:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07441 for ; Tue, 19 Mar 2002 18:10:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24848 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 18:11:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24045; Tue, 19 Mar 2002 17:59:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23982 for ; Tue, 19 Mar 2002 17:59:23 -0500 (EST) Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07200; Tue, 19 Mar 2002 17:59:20 -0500 (EST) Received: from eburger (eburger.ietf53.cw.net [166.63.189.43]) by noc-e.ietf53.cw.net (Postfix) with SMTP id E264C6A928; Tue, 19 Mar 2002 16:59:22 -0600 (CST) Reply-To: From: "Eric Burger" To: "Sipping" , "SIP List" , Date: Tue, 19 Mar 2002 17:59:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Conferencing Bar Ad Hoc Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Let's meet after the MMUSIC session around 11:45am in the Harmony Lounge (a real Bar!). They have a buffet and comfy tables. For those new to the subject, this is an informal get-together to discuss conferencing issues. For a count, please reply to me PERSONALLY (and NOT on the list) if you plan on attending. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 18:37:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07939 for ; Tue, 19 Mar 2002 18:37:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26171 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 18:37:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25255; Tue, 19 Mar 2002 18:21:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25230 for ; Tue, 19 Mar 2002 18:21:17 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07625 for ; Tue, 19 Mar 2002 18:21:13 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2JNKhh26762; Tue, 19 Mar 2002 15:20:43 -0800 (PST) Received: from oranlt (sjc-vpn2-284.cisco.com [10.21.113.28]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACJ52406; Tue, 19 Mar 2002 15:20:54 -0800 (PST) From: "David R. Oran" To: , "'Rohan Mahy'" Cc: Subject: RE: [Sip] Reason header simplification Date: Tue, 19 Mar 2002 18:20:44 -0500 Organization: Cisco Systems Message-ID: <007501c1cf9c$b2365ec0$13bf3fa6@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This approach seems eminently reasonable to me. For documentation purposes it probably makes sense to have a table which says which "response codes" make sense in Reponses only; which make sense as reason codes in requests only, and which makes sense in both. Even if all make sense in both, it's important to document the usage subtleties. I'm agnostic on the issue of whether we should both caring additional information beyond a text of the reason in the reason header. Dave. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Eric Burger > Sent: Tuesday, March 19, 2002 5:12 PM > To: Rohan Mahy > Cc: sip@ietf.org > Subject: RE: [Sip] Reason header simplification > > > The reason for Reason :-) is for the "extra info" that's > behind the result code. Sort of an Error-Info short-hand > (should it be such?). > > A model that this reminds me of is the VAX VMS return > structure. There's the return code (which I agree with > Rohan, is simply the SIP return code). Then there's the > readable text. Then there's the useful info. > > Clearly the "useful" info is situation-specific. This is > where the rest of the Reason information, *including* > Q.mumble, H.foo, Unix Process Exit Value, etc. is important. > > The other place for Reason is to address History. The SIP > result code is for *this* request. There's a need for > knowing other result codes this request has been exposed to > during its life. > > I would propose a Reason: header that is composed of the > *SIP* result code (as Rohan suggests) with enriched, > application-specific information (as Henning/Gonzalo suggest). > > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Rohan Mahy > Sent: Tuesday, March 19, 2002 3:32 PM > To: gonzalo.camarillo@ericsson.com > Cc: sip@ietf.org > Subject: [Sip] Reason header simplification > > > Hi, > > It occurred to me that there is a lot of overlap between the > 1-9 reason codes in the reason header, and the 3 digit SIP > reason codes. I think these could be consolidated as described below. > > Reason: 1 (call completed elsewhere) in a CANCEL could > instead become a CANCEL with a Reason: 200 OK (you are > receiving a CANCEL because the status of the call was a 200 > OK, presumably from another branch). > > The only difference between Reason 2 (abandoned) and Reason 4 > (terminated) is that 2 is used in CANCEL, and 4 is used for > BYE. We could allocate a new 4xx response code (say 499) for > "terminated" and use this instead. This response code would > also be useful in the call-info package. > > Reason: 3 (timed out) is easily expressed with Reason: 408 Timeout > > Reason: 5 (transfer complete) isn't needed because a > notification to that effect is generated when using REFER > > Reason: 6 (no media) could be represented with a new response > code (say > 498) > > Reason: 7 (interworking) does really have any semantic > meaning, so just use the SIP response code. > > Reason: 8 (offer refused) sounds like a 603 Decline or 488 > Incompatible Media to me. The SIP responses are actually > more rich, but not significantly more complex. > > Reason: 9 (update requested) can be implied by the fact that > the reason header is in a 155 response. the "real" reason is > the repairable error > > > Also I don't like to idea of sending ISUP (Q.850) or ISDN > (Q.931) response codes around inside a SIP network. I'd > rather use standard ISUP-SIP or ISDN-SIP cause code > translation, so that an ordinary SIP UA can just use a set of > well-defined SIP cause codes. > > hope this makes sense. > > thanks, > -rohan > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 19:33:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08838 for ; Tue, 19 Mar 2002 19:32:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28662 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 19:32:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27703; Tue, 19 Mar 2002 19:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27676 for ; Tue, 19 Mar 2002 19:14:38 -0500 (EST) Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08520 for ; Tue, 19 Mar 2002 19:14:36 -0500 (EST) Message-ID: <20020320001437.86384.qmail@web11606.mail.yahoo.com> Received: from [166.63.189.85] by web11606.mail.yahoo.com via HTTP; Tue, 19 Mar 2002 16:14:37 PST Date: Tue, 19 Mar 2002 16:14:37 -0800 (PST) From: Sean Olson Subject: Re: [Sip] SIP Change Process To: "Fairlie-Cuninghame, Robert" , "'sip@ietf.org'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sounds like the problem has been solved: P-Supported, P-Require: Seriously, relaxing the process to allow these option tags in Supported: sounds like a good idea. /sean --- "Fairlie-Cuninghame, Robert" wrote: > > I believe that the SIP Change Process should be > relaxed to allow > non-chartered SIP extensions to define SIP option > tags for use in Supported > but but not in Require. > > Unless the aim of this draft is to prevent any > non-chartered work from doing > anything useful, this is an important distinction. > > I also see the current restriction (no option tags > whatsoever) as actually > counter-productive to the future state of the > protocol - it simply forces > authors to generate additional P-headers to indicate > the ability to support > an uncharter extension. > > Take as an example a typical P- compliant service > such as media > authorization. An entity may desire to know whther > an access network > supports media authorization before blindly placing > a call with the P- media > authorization header. Forcing networks to statically > configure this > knowledge is not desirable. Forcing authors to > invent separate P- headers to > indicate support for media authorization is not > desirable. [I merely use > this as an example; I am not saying that this needs > to be added to that > particular draft.] > > Another argument: If someone writes a "P-Supported" > extension draft then I > beleive that this extension exactly falls into the > restrictions of the SIP > Change Process itself. The Supported header merely > provides transparent > information - exactly what P-headers were designed > for. Thus, there should > not be a restriction on the use of option tags > within the normal Supported > header. Require yes, Supported no. > > As I said before, this eases migration of > unchartered work group items into > chartered items, that is, authors do not need to > invent specific P-header > mechanisms to cover the inability to use the normal > Supported header. > > That's my two cents anyway. > > Cheers, > > Robert. > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 19 20:44:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09953 for ; Tue, 19 Mar 2002 20:44:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA01420 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 20:44:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00535; Tue, 19 Mar 2002 20:25:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00510 for ; Tue, 19 Mar 2002 20:24:57 -0500 (EST) Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09593 for ; Tue, 19 Mar 2002 20:24:54 -0500 (EST) Message-ID: <20020320012456.70583.qmail@web11607.mail.yahoo.com> Received: from [166.63.189.85] by web11607.mail.yahoo.com via HTTP; Tue, 19 Mar 2002 17:24:56 PST Date: Tue, 19 Mar 2002 17:24:56 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Requirements on Reason information. New I-D To: "Vijay K. Gurbani" , Gonzalo Camarillo Cc: sip , spirits@lists.bell-lab.com In-Reply-To: <3C97BBD6.46BBFB3@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a very slippery slope. Although it is just as problematic, I would prefer the use of the Server: header for this task. The less the PSTN pollutes the SIP protocol, the better. /sean --- "Vijay K. Gurbani" wrote: > Gonzalo Camarillo wrote: > > > > Chairmen, > [...] > > I have put together an I-D with those > requirements. > > > > > http://standards.ericsson.net/gonzalo/draft-camarillo-sipping-reason-00.txt > > > > I would like to know if these requirements are > what you expected or if, > > on the other hand, you wanted something else... > > > > I intend to submit this draft, including the > comments I may receive, on > > Monday. > > One more service that can be added in Section 5 of > your I-D is SPIRITS-based > services. A UA getting an INVITE may benefit from > having a Reason header to > make a determination if the invitation resulted from > the PSTN domain. > > Likewise the header may help UACs that get a final > response from a SIP/IN > entity. > > Regards, > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 Fax: +1 630 713 0184 > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 23:11:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14026 for ; Tue, 19 Mar 2002 23:11:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA07567 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 23:11:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06527; Tue, 19 Mar 2002 22:58:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06495 for ; Tue, 19 Mar 2002 22:58:29 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13750 for ; Tue, 19 Mar 2002 22:58:25 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2K3wMl01063; Tue, 19 Mar 2002 21:58:22 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2K3wMt08834; Tue, 19 Mar 2002 21:58:22 -0600 (CST) Received: from lmf.ericsson.se (rmt160166.am.ericsson.se [138.85.160.166]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA22976; Tue, 19 Mar 2002 21:58:20 -0600 (CST) Message-ID: <3C98097E.E1F8F3A7@lmf.ericsson.se> Date: Wed, 20 Mar 2002 06:01:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Jonathan Rosenberg , sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Offer by the callee Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Setting the port number to zero means refusal of the stream, so you are risking that the caller sends a CANCEL, since you have refused all the media streams. A better solution would be to send a held SDP (a=inactive). Regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello, > > I'm trying to connect the offer/answer, update and manyfolks drafts for the > following scenario: > - Alice sends an INVITE to Bob with "offer-1" > - Bob wants to make an "offer-2" to Alice, before the completion of the > session establishment > - Bob would like to ask Alice to start resource reservation only based on > the acceptation of "offer-2", and not before (in fact Bob knows that it is > useless to start resource reservation based on offer-1, because he knows he > will send immediatly a new offer-2, but he is obliged to wait for Prack > before) > > The Update draft defines the response 155 to allow the answerer (the callee > in our case) to request "Mr. the calling, please *send me* a new offer", > but there is no way for the same callee to announce "Mr. the calling, *I > want to send you* a new offer right now". > So, one possible way to achieve that is that the callee sends an answer to > the original offer but disabling all the media (in order to avoid to start > resource reservation), and next proposing a new offer, as described in the > call flow below (assume for the example that they are using end-to-end > resource reservation, but please don't generate a new debate on this > topic): > > Alice > Bob > INVITE (offer-1) > -----------------------------------------------------------------> > 183 (answer-to-offer-1, all port numbers to zero) > <----------------------------------------------------------------- > PRACK > -----------------------------------------------------------------> > 200 PRACK > <----------------------------------------------------------------- > UPDATE (offer-2, status-type=e2e) > <----------------------------------------------------------------- > 200 UPDATE (answer-to-offer-2) > -----------------------------------------------------------------> > > <========== Resource Reservation ==========> > > UPDATE (current-status = desired-status) > -----------------------------------------------------------------> > 200 UPDATE > <----------------------------------------------------------------- > 200 INVITE > <----------------------------------------------------------------- > ACK > -----------------------------------------------------------------> > > Is this scenario compliant with the drafts Offer/Answer, Update and > Manyfolks ? > > Thank you for your answer > Best regards > Juan Carlos -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Tue Mar 19 23:11:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14042 for ; Tue, 19 Mar 2002 23:11:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA07581 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 23:11:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06293; Tue, 19 Mar 2002 22:49:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06233 for ; Tue, 19 Mar 2002 22:49:20 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13630; Tue, 19 Mar 2002 22:49:16 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2K3mgi22566; Tue, 19 Mar 2002 21:48:42 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2K3mgx04404; Tue, 19 Mar 2002 21:48:42 -0600 (CST) Received: from lmf.ericsson.se (rmt160166.am.ericsson.se [138.85.160.166]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA22217; Tue, 19 Mar 2002 21:48:40 -0600 (CST) Message-ID: <3C98073A.4720EEC@lmf.ericsson.se> Date: Wed, 20 Mar 2002 05:51:22 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: eburger@snowshore.com CC: SIP List , Sipping Subject: Re: [Sip] Requirements on Reason information. New I-D References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Eric, Eric Burger wrote: > If we can carry and identify the source of the Reason headers, like we do > for Via or SMTP does for Received-By, then this header can satisfy both > camarillo-sipping-reason's and watson-sipping-req-history's requirements. > In the SIP WG meeting Dave Oran explicitly asked to leave out of this work any identification stuff, and there was rough (actually total) consensus about it. Therefore, I do not think it is appropriate to try to pull it in at this point of time. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 23:25:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14197 for ; Tue, 19 Mar 2002 23:25:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08233 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 23:25:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07690; Tue, 19 Mar 2002 23:13:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07658 for ; Tue, 19 Mar 2002 23:13:19 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14090 for ; Tue, 19 Mar 2002 23:13:14 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 23:12:47 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46A96161@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: sip@ietf.org Date: Tue, 19 Mar 2002 23:12:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Manyfolks Clarifications Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Firstly, just wanted to say that the draft now looks significantly better given the inclusion as requested of desired and current status, separation of direction-tags in offers when necessary, as well as specific rules for agreeing lead roles. This makes the preconditions exchanges so much more efficient now although I am a little disappointed that my contributions in this regard have not been acknowledged. The draft is also now much clearer in many areas as to what actually happens, and when, so good job there from an editing perspective. However, there still appears to be major confusion left in the area of the e2e v local/remote tags, and what state the UA uses in deciding which to use. Ideally, the aim is that preconditions, whilst trying to couple SDP with QoS mechanisms, is independent of those mechanisms. However, with the two choices available to the UA (e2e or local/remote) status types the draft needs to be very clear about the state and rules used by a UA in inserting those status tags. I cannot from the draft unambiguously identify what those rules are and I believe much of the feedback related to the status tags is due to this confusion. To try to tease out the state and rules I have listed below some QoS scenarios Gonzalo and I would appreciate it if you could let me know how each UA should act in each case, assuming correct protocol by all elements, by stating which status tag should be used and how the UA knows to use that tag (ie what state is interrogated). By all means just initially put the testcase numbers and letters under either local/remote or e2e columns and I'll follow up with specific queries about why and how (what UA state triggers the decision). First some terminology.. end to end : UA to UA access: customer router to first core router LAN: bandwidth rich network between UA and access core: first to last core router including arbitrary transit domains and associated QoS mechanisms banana: any hop by hop QoS protocol that triggers admission control checks at each hop non-banana cloud : a sequence of n routers that do not process banana hop by hop QoS protocol messages banana-diff edge : a router at which banana triggers admission control checks into a diff-serv BA (aggregate) banana-null edge : a router at which banana triggers admission control checks into the next link only diff cloud: a sequence of routers between two banana-diff edges where aggregate resources exist null cloud: a sequence of routers between two banana-null edges where available resources are unknown Test Cases Assume in all cases that banana carries information as to whether a non-RSVP cloud was traversed and also carries admission control success or failures between the two banana end points. In each case please indicate if the preconditions will be satisfied if banana indicates a non-banana cloud with an admission control / reservation success (it is obvious they will not be met if any admission control failure is reported) 1. Network Topology UA-access-core-access-UA a) End to end banana where core is a diff-cloud b) End to end banana where core is a null-cloud c) UA to core banana at both ends with banana-diff edges into a diff-serv cloud d) UA to core banana at both ends with banana-null edges into a non-banana cloud e) end to end banana with a non-banana cloud on one access with banana-diff edge at core access router f) end to end banana with a non-banana cloud on one access with banana-null edge at core access router g) UA to core diff clouds at both ends with banana trunk across the core with diff-banana edges h) end to end banana where no core element speaks banana (ie one big null-cloud) i) end to end banana where no core element speaks banana (ie one big diff-cloud) 2. Network Topology UA-access-access-UA (no core cloud due to common access-core router) c) to i) above with missing cloud 3. Network Topology UA-LAN-UA a) end to end banana with no LAN QoS (null-could) b) end to end banana with LAN QoS (diff-cloud) c) end to end banana with one UA not supporting banana 4. Network Topology UA-LAN-access-core-LAN-UA (on gateway) a) end to end banana with non-banana cloud between core-LAN-UA b) UA to core banana where core is diff-serv cloud with a banana-diff edge c) UA to core banana where core is null-cloud d) null-cloud UA to core with core to gateway banana trunk and null-banana edge e) diff-cloud UA to core with core to gateway banana trunk and diff-banana edge The objective here is to identify how much the UA is relying on information in its SLA, on its available QoS mechanisms, on its topology awareness, and on feedback from SDP preconditions and QoS mechanisms. I may need to use additional examples to further tease out what is known and what is assumed by the UA to correctly use e2e v local/remote tags... I am not suggesting we need to explore and document all scenarios but I think we do need to identify and definitively document the distinguishing characteristics and state so that an implementor and two peer UAs on different ISP networks will do the right thing in all cases... Gonzalo - feel free to alternatively state the definitive distinguishing characteristics, UA state and non-banana cloud interpretation as you see them, rather than going through the test cases, if you feel they are already clear..and I am simply misunderstanding the architecture.. Regards, Alan. Acknowledgements I'd like to thank Xin Chen for the generic banana QoS signalling framework :-) _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 23:53:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15176 for ; Tue, 19 Mar 2002 23:53:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA09898 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 23:53:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09122; Tue, 19 Mar 2002 23:35:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09092 for ; Tue, 19 Mar 2002 23:35:03 -0500 (EST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14710 for ; Tue, 19 Mar 2002 23:34:58 -0500 (EST) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.10.1/8.10.1) with ESMTP id g2K4YMb28757; Tue, 19 Mar 2002 21:34:22 -0700 (MST) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 21:34:22 -0700 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF0316C5B3@srvmail.cablelabs.com> From: Jean-Francois Mule To: "'Rohan Mahy'" , gonzalo.camarillo@ericsson.com Cc: sip@ietf.org Subject: RE: [Sip] Reason header simplification Date: Tue, 19 Mar 2002 21:34:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Rohan wrote: > Also I don't like to idea of sending ISUP (Q.850) or ISDN > (Q.931) response > codes around inside a SIP network. Actually, I like that option a lot since mapping is almost never a one to one exercize when translating cause codes or release reason codes between protocols. This is why some other protocols have also gone that route of "encapsulating" the q.850 codes inside release or release complete messages in order to have transparency. > I'd rather use standard > ISUP-SIP or > ISDN-SIP cause code translation, so that an ordinary SIP UA > can just use a set of well-defined SIP cause codes. The requirement expressed here is something like "whenever possible, a SIP cause code should also be provided". The reason header draft could clarify the rules of dealing with multiple reason header lines (we could have q.850 reason codes carried for end-to-end purposes or other H.323/SIP inter-working functions but still mandate a sip reason header line for the signaling hops along the sip chain). Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 19 23:56:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15248 for ; Tue, 19 Mar 2002 23:56:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA10053 for sip-archive@odin.ietf.org; Tue, 19 Mar 2002 23:56:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09796; Tue, 19 Mar 2002 23:46:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09764 for ; Tue, 19 Mar 2002 23:46:44 -0500 (EST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15006 for ; Tue, 19 Mar 2002 23:46:39 -0500 (EST) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.10.1/8.10.1) with ESMTP id g2K4kCb28886 for ; Tue, 19 Mar 2002 21:46:12 -0700 (MST) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 21:46:12 -0700 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF0316C5B4@srvmail.cablelabs.com> From: Jean-Francois Mule To: sip@ietf.org Subject: RE: [Sip] Reason header and call diversion Date: Tue, 19 Mar 2002 21:46:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I was just wondering whether the reason header draft could become a foundation for solving the call diversion draft requirements, those issues that were put to rest some time ago. The text is pretty close to eluding to call diversion/redirection but it falls short of mentioning it. Is it just a matter of defining additional reason-text and reason-extension params for call diversion now? Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 00:02:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15379 for ; Wed, 20 Mar 2002 00:02:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10633 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 00:02:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09669; Tue, 19 Mar 2002 23:45:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09641 for ; Tue, 19 Mar 2002 23:45:39 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14979 for ; Tue, 19 Mar 2002 23:45:35 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2K4jbl08841; Tue, 19 Mar 2002 22:45:37 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2K4jax10386; Tue, 19 Mar 2002 22:45:36 -0600 (CST) Received: from lmf.ericsson.se (rmt160166.am.ericsson.se [138.85.160.166]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA29007; Tue, 19 Mar 2002 22:45:33 -0600 (CST) Message-ID: <3C98148B.4502FDA@lmf.ericsson.se> Date: Wed, 20 Mar 2002 06:48:11 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: sip@ietf.org References: <8C92E23A3E87FB479988285F9E22BE46A96161@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks Clarifications Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Alan, > Ideally, the aim is that preconditions, whilst trying to couple SDP > with QoS mechanisms, is independent of those mechanisms. Yes, that's the idea. > However, with the > two choices available to the UA (e2e or local/remote) status types the draft > needs to be very clear about the state and rules used by a UA in inserting > those status tags. The rule is: if you have a way of knowing that there is end to end QoS, you can use e2e. Otherwise you would never know whether there is actually e2e QoS or not. For example, if I have an end to end protocol that tells me that there are resources end to end, I can use the end to end tag. However, if I do not have a way of knowing that there are end to end resources and I use the e2e tag, I will be locked for ever, because I cannot know anything about the current status. About DiffServ and SLAs: Let's assume I call you and I know that you are connected to the same DiffServ network as I am connected and that this network will always provide a certain QoS to my marked traffic. I also know that you are on a 100 based-T ethernet. Then, I can set the current status to e2e sendrecv even before sending my INVITE... but the problem is that, before making the call, you do not typically know in which terminal you are going to be available. That's why you will typically need an end to end QoS reservation protocol. > 1. Network Topology UA-access-core-access-UA > > a) End to end banana where core is a diff-cloud I do not think this examples are going to be helpful to understand the problem. Again, if banana tells you when e2e QoS has been achieved, you can use e2e. If not, you cannot. > b) End to end banana where core is a null-cloud The same as above. > c) UA to core banana at both ends with banana-diff edges into a diff-serv > cloud Again, if you has any means to know whether the other end is connected to the same DiffServ cloud as you and you are also sure that both the callee and the caller have SLAs with the cloud, you could use e2e. If you do not know that, you cannot use e2e. > d) UA to core banana at both ends with banana-null edges into a non-banana The same as above. > cloud > e) end to end banana with a non-banana cloud on one access with banana-diff > edge at core access router The same as in every single bullet. If banana tells you that there is end to end QoS, you can use e2e. > f) end to end banana with a non-banana cloud on one access with banana-null Same as above. > edge at core access router > g) UA to core diff clouds at both ends with banana trunk across the core > with diff-banana edges > h) end to end banana where no core element speaks banana (ie one big > null-cloud) I do not think it is worthwhile going on with this specific cases. I have explained the general rule above. I believe that the missunderstanding comes from trying to mix the actual QoS protocol with manyfolks. Here we define preconditions. Other WGs define QoS protocols. Therefore, if your banana messages traverse a non-banana cloud and cannot ensure that there is QoS, too bad. But it is a problem related to the QoS protocol, not to manyfolks. Fix banana or make every core system support banana and you have your problem resolved. You can also implement gateways and a discovery mechanism or whatever you want, but this is not a problem related to the preconditions. > The objective here is to identify how much the UA is relying on information > in its SLA, on its available QoS mechanisms, on its topology awareness, and > on feedback from SDP preconditions and QoS mechanisms. You rely on any information you have. If by inspecting the remote contact header I am sure that you are in the same ethernet as I am, I will be able to set current status to sendrecv. To give you a more radical example of the information you can use, I can call you and you are in the same office as me. Since I see that your ethernet cable is connected to the same hub as mine, I can set the current status to sendrecv. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 02:57:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25919 for ; Wed, 20 Mar 2002 02:57:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28327 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 02:57:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA28012; Wed, 20 Mar 2002 02:42:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27911 for ; Wed, 20 Mar 2002 02:42:03 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25781 for ; Wed, 20 Mar 2002 02:42:01 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id IAA05192; Wed, 20 Mar 2002 08:41:16 +0100 (MET) Subject: Re: [Sip] Re: Offer by the callee To: Gonzalo Camarillo Cc: Jonathan Rosenberg , sip@ietf.org Date: Wed, 20 Mar 2002 08:41:14 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/20/2002 08:41:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Thank you for your answer You are right, but sending a held SDP does not prevent the calling party to start resource reservation, but only to send media. I agree with you that normally, a port number to zero indicates refusal of the media stream. Nevertheless, according to Offer/Answer draft, all port numbers equal to zero is used also to announce capabilities (section 9), and very often it is used to say just "don't use this media". What I need here is to give to the answerer the possibility to say "Mr.the Offerer, I'm not rejecting your Invite, but I'd like to send you a new offer right now, so it is useless to start resource reservation before receiving this new offer" Best regards Juan Carlos Gonzalo Camarillo @ietf.org on 20/03/2002 05:01:02 Sent by: sip-admin@ietf.org To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: [Sip] Re: Offer by the callee Hi, Setting the port number to zero means refusal of the stream, so you are risking that the caller sends a CANCEL, since you have refused all the media streams. A better solution would be to send a held SDP (a=inactive). Regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hello, > > I'm trying to connect the offer/answer, update and manyfolks drafts for the > following scenario: > - Alice sends an INVITE to Bob with "offer-1" > - Bob wants to make an "offer-2" to Alice, before the completion of the > session establishment > - Bob would like to ask Alice to start resource reservation only based on > the acceptation of "offer-2", and not before (in fact Bob knows that it is > useless to start resource reservation based on offer-1, because he knows he > will send immediatly a new offer-2, but he is obliged to wait for Prack > before) > > The Update draft defines the response 155 to allow the answerer (the callee > in our case) to request "Mr. the calling, please *send me* a new offer", > but there is no way for the same callee to announce "Mr. the calling, *I > want to send you* a new offer right now". > So, one possible way to achieve that is that the callee sends an answer to > the original offer but disabling all the media (in order to avoid to start > resource reservation), and next proposing a new offer, as described in the > call flow below (assume for the example that they are using end-to-end > resource reservation, but please don't generate a new debate on this > topic): > > Alice > Bob > INVITE (offer-1) > -----------------------------------------------------------------> > 183 (answer-to-offer-1, all port numbers to zero) > <----------------------------------------------------------------- > PRACK > -----------------------------------------------------------------> > 200 PRACK > <----------------------------------------------------------------- > UPDATE (offer-2, status-type=e2e) > <----------------------------------------------------------------- > 200 UPDATE (answer-to-offer-2) > -----------------------------------------------------------------> > > <========== Resource Reservation ==========> > > UPDATE (current-status = desired-status) > -----------------------------------------------------------------> > 200 UPDATE > <----------------------------------------------------------------- > 200 INVITE > <----------------------------------------------------------------- > ACK > -----------------------------------------------------------------> > > Is this scenario compliant with the drafts Offer/Answer, Update and > Manyfolks ? > > Thank you for your answer > Best regards > Juan Carlos -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 03:44:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26457 for ; Wed, 20 Mar 2002 03:44:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00623 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 03:45:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29520; Wed, 20 Mar 2002 03:19:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29489 for ; Wed, 20 Mar 2002 03:19:31 -0500 (EST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26190 for ; Wed, 20 Mar 2002 03:19:28 -0500 (EST) Received: from libero.it (193.70.192.63) by smtp2.libero.it (6.5.015) id 3C9619640012A28E for sip@ietf.org; Wed, 20 Mar 2002 09:18:59 +0100 Date: Wed, 20 Mar 2002 09:18:59 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q??=" To: sip@ietf.org X-XaM3-API-Version: 301build11 X-type: 0 X-SenderIP: 193.205.164.67 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA29490 Subject: [Sip] =?iso-8859-1?Q?test_don't_open?= Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 03:45:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26474 for ; Wed, 20 Mar 2002 03:45:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA00644 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 03:45:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29479; Wed, 20 Mar 2002 03:19:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA29450 for ; Wed, 20 Mar 2002 03:19:19 -0500 (EST) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26188 for ; Wed, 20 Mar 2002 03:19:15 -0500 (EST) Received: from libero.it (193.70.192.63) by smtp1.libero.it (6.5.015) id 3C95D53C00164FF1 for sip@ietf.org; Wed, 20 Mar 2002 09:18:46 +0100 Date: Wed, 20 Mar 2002 09:18:45 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q??=" To: sip@ietf.org X-XaM3-API-Version: 301build11 X-type: 0 X-SenderIP: 193.205.164.67 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA29451 Subject: [Sip] =?iso-8859-1?Q?test_don't_open?= Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 04:17:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26796 for ; Wed, 20 Mar 2002 04:17:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02217 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 04:17:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01027; Wed, 20 Mar 2002 03:54:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00997 for ; Wed, 20 Mar 2002 03:54:54 -0500 (EST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26602 for ; Wed, 20 Mar 2002 03:54:41 -0500 (EST) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g2K8jBU18921 for ; Wed, 20 Mar 2002 10:45:11 +0200 Received: by il-tlv-mbdg2.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Mar 2002 10:54:42 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] Question on CANCEL - backwards-compatibility Date: Wed, 20 Mar 2002 10:54:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFEC.DF8B14B0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1CFEC.DF8B14B0 Content-Type: text/plain; charset="iso-8859-1" Hi, Early bis drafts support CANCEL for any request. How UAS (bis 09) should respond to CANCEL for none-INVITE request from UAC (early bis) ? Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Tuesday, March 19, 2002 4:43 PM To: Fuxbruner, Amihay Cc: sip@ietf.org Subject: Re: [Sip] Question on UPDATE after INVITE completion Hello, "Fuxbruner, Amihay" wrote: > > What is the purpose of sending UPDATE after INVITE completion ? > Is this another way for re-INVITE ? UPDATE involves only two messages, so it can be useful for saving bandwidth. re-INVITE is still needed, though, because in some scenarios you cannot provide an offer in the re-INVITE, and you have to wait for an offer in the response. UPDATe does not support this three-way-handshake. Regards, Gonzalo ------_=_NextPart_001_01C1CFEC.DF8B14B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Sip] Question on CANCEL - backwards-compatibility

Hi,

Early bis drafts support CANCEL for any = request.
How UAS (bis 09) should respond to CANCEL for = none-INVITE request from UAC (early bis) ?

Thanks,

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse


-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
Sent: Tuesday, March 19, 2002 4:43 PM
To: Fuxbruner, Amihay
Cc: sip@ietf.org
Subject: Re: [Sip] Question on UPDATE after INVITE = completion


Hello,

"Fuxbruner, Amihay" wrote:
>
> What is the purpose of sending UPDATE after = INVITE completion ?
> Is this another way for re-INVITE ?

UPDATE involves only two messages, so it can be = useful for saving
bandwidth. re-INVITE is still needed, though, = because in some scenarios
you cannot provide an offer in the re-INVITE, and = you have to wait for
an offer in the response. UPDATe does not support = this
three-way-handshake.

Regards,

Gonzalo

------_=_NextPart_001_01C1CFEC.DF8B14B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 04:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26948 for ; Wed, 20 Mar 2002 04:28:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA02471 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 04:28:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01694; Wed, 20 Mar 2002 04:01:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01651 for ; Wed, 20 Mar 2002 04:01:28 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26668 for ; Wed, 20 Mar 2002 04:01:24 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA28966 for ; Wed, 20 Mar 2002 10:01:14 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA28302 for ; Wed, 20 Mar 2002 10:01:06 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 10:01:42 +0100 Message-ID: From: Ruppelt Christian To: sip@ietf.org Date: Wed, 20 Mar 2002 10:01:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] question on privacy 04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org How could the Proxy-o determine the identity of UA-o (see basic privacy example)? The From field (cryptographically random identifier, non identifying hostname) could not be used for this. The Remote-Party-ID header is not sent by UA-o. regards Christian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 06:37:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28066 for ; Wed, 20 Mar 2002 06:37:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA07938 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 06:37:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06739; Wed, 20 Mar 2002 06:03:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA06707 for ; Wed, 20 Mar 2002 06:03:53 -0500 (EST) Received: from hotsip.com ([212.28.214.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27759 for ; Wed, 20 Mar 2002 06:03:48 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 20 Mar 2002 12:03:20 +0100 Message-ID: Thread-Topic: bis-09 references non existing definition. Thread-Index: AcHP/woCzJY6DRyyToKCFR95/EiaRg== From: "Christian Jansson" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA06708 Subject: [Sip] bis-09 references non existing definition. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit 17.2.3 Matching Requests to Server Transactions, line 3520: "Matching is done based on the matching rules defined for each of those header fields." But there is no matching rule defined for the Via header. Maybe there should be one. ---------------------- Christian Jansson Hotsip AB Barnhusgatan 16 111 23 Stockholm Tel: 08 454 05 04 Mob: 0739 888 163 ---------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 07:23:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28508 for ; Wed, 20 Mar 2002 07:23:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA09577 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 07:22:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08438; Wed, 20 Mar 2002 06:57:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08407 for ; Wed, 20 Mar 2002 06:57:29 -0500 (EST) Received: from kaula.innovaphone.int (innovaphone.com [195.226.104.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28271 for ; Wed, 20 Mar 2002 06:57:26 -0500 (EST) Received: by kaula.innovaphone.int with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 12:57:21 +0100 Message-ID: <1921644655FE154BB2381C086C4FD8E305187E@kaula.innovaphone.int> From: Guntram Diehl To: "'sip@ietf.org'" Date: Wed, 20 Mar 2002 12:57:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] media coder negociation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, can anybody tell me if there is already any work concerning media coder negociation within sip in progress? There seems to be a need for this for several reasons: - SIP - H.323 interworking - RSVP: You have to make reservations with RSVP as receiver of the media stream. How can you make reservations if you don't know which one of the different sessions you annouce via SDP is used by the other side. - Most of the available DSP software for coders support symmetric coders only. Guntram _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 09:06:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29811 for ; Wed, 20 Mar 2002 09:06:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15462 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 09:06:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11936; Wed, 20 Mar 2002 08:03:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11817 for ; Wed, 20 Mar 2002 08:02:55 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28886 for ; Wed, 20 Mar 2002 07:58:45 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2KCvqt23424; Wed, 20 Mar 2002 13:57:53 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 12:57:56 -0000 Message-ID: From: "Mark Watson" To: "'Peterson, Jon'" , "'sip@ietf.org'" Subject: RE: [Sip] comments on privacy-04 Date: Wed, 20 Mar 2002 12:57:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D00E.D64C03B0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D00E.D64C03B0 Content-Type: text/plain; charset="iso-8859-1" Jon, all, With respect to the charter & the privacy draft, I guess we can argue which was chicken & which was egg. Both have been as they are now for some time without comment. I think, as discussed before WGLC, that extensibility is important. When/if new identity types are required to be carried by Remote-Party-ID, we can add these and be sure that the correct privacy handing takes place at proxies which do not recognise the new identity type. This would not be the case for new headers. Also, I think RPID should be self-qualifying, in that you should not have to look at the context (in terms of the individual message) to determine to whom the identity applies. This makes things simpler to understand and supports future re-use in other contexts. Any text saying that implications should be drawn from the particular message in which RPID appears, I think should be amended. I agree completely with your desire to remove the factors which cause people to put gobbledegook in From:/To:. A general URI parameter as you suggest would allow 'private'(*) or 'potentially private' (**) information to be passed to trusted proxies in From:/To: by a UA. This may also remove the arguments for inserting RPID at an untrusted UA. This is supposing that the URI parameter MUST be acted on by devices supporting the Proxy-Require: privacy tag. This in turn implies a requirement for those devices to be able to route via another device/function which can modify the From/To fields. [Let's not argue now about what such a device is called :-)] (*) By 'private' I mean that the information cannot be passed to other UAs, but is required to be visible to (trusted) network entities. (**) Information inserted by the UAC may become 'private' without the knowledge of the UAC due to the operation of services in the network. Such 'potentially private' information cannot presently be placed in From/To without a means of marking the privacy status and modifying the information as described above. Finally, regarding 'subscriber' and 'user', one definition of these appears in the European Union Directive on protection of privacy in telecommunications networks: (a) 'subscriber` shall mean any natural or legal person who or which is party to a contract with the provider of publicly available telecommunications services for the supply of such services; (b) 'user` shall mean any natural person using a publicly available telecommunications service, for private or business purposes, without necessarily having subscribed to this service; (c) 'public telecommunications network` shall mean transmission systems and, where applicable, switching equipment and other resources which permit the conveyance of signals between defined termination points by wire, by radio, by optical or by other electromagnetic means, which are used, in whole or in part, for the provision of publicly available telecommunications services; (d) 'telecommunications service` shall mean services whose provision consists wholly or partly in the transmission and routing of signals on telecommunications networks, with the exception of radio- and television broadcasting. I think these terms are pretty much applicable to SIP services, certainly within the realm of applicability of this privacy draft. If people are not happy with the common sense meanings of the terms, then we could include the above definitions. Regards...Mark > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: 18 March 2002 17:04 > To: 'sip@ietf.org' > Subject: [Sip] comments on privacy-04 > > > > Since we now have a WGLC on sip-privacy-04, I have a couple > of comments that > I apologize in advance for not presenting earlier. > > I think that SIP needs a network-provided privacy mechanism, > and I think the > system described by this draft is a reasonable solution to > that problem. > However, the sip-privacy-04 system is more complicated than > it needs to be > in order to solve this problem, and these complexities give rise to > confusions about the implementation and applicability of the > mechanism. > Today, the SIP charter speaks to a need for privacy > mechanisms but not, for > example, for new identity-assertion mechanisms. > > Jon Peterson > NeuStar, Inc. > > ----- > > - rpi-screen: As the recent thread in the SIP ML suggested, > the behavior in > sip-privacy-04 for handling RPIDs received from an untrusted > source might be > confusing. If untrusted entities shouldn't add the RPID > header (which I > gather from the applicability), then why not say that a proxy > MUST remove > any RPID headers it receives from an untrusted source? Today, > it sets the > 'screen=no' parameter instead. However, no behavior in the document is > defined for using an RPID header with 'screen=no' - it merely > says that a UA > that receives it in a message shouldn't trust it (although what exact > behavior this entails is unclear). If this is totally deadweight in > signaling, it should just be removed - SIP messages don't > need any help > getting larger. If you receive a RPID from a trusted entity, > 'screen=yes' > could just be assumed; a parameter that says "trust me" may > very well be > redundant in a trusted network. If it turns out that an RPID > that the proxy > will add itself is identical to an RPID that has been supplied by an > untrusted source, then while this may be just lip service I > think the least > ambiguous and most secure language is still to say that the > proxy removes > the untrusted header and adds a trusted header. If for > whatever reason it > turns out we do need this parameter, the idea that both > 'screen=yes' and > 'screen=no' can appear in the same RPID header (this is > permitted in 6.1) > must be unnecessary. Finally, if you are going to have this parameter, > calling it "screen" is a little misleading; screening in the > PSTN can refer > to selectively blocking calls based on the original > calling/called number > (to me it implies that some feature has been invoked that > inspects the ANI > and the dialed number and determines that this is a > legitimate target for > the caller's class of service). Maybe "verify" would make more sense. > > - rpi-pty-type: This parameter allows you to specify which > party's identity > is contained in the RPID header ("calling" or "called" are currently > allowed). However, no motivation for this capability is > presented in the > draft - it defines the conditions under which these > parameters are inserted, > but there is no recipient behavior that justifies their > insertion. Moreover, > the behavior for adding the parameter holds only that a > request contains a > 'calling' id, and the response contains a 'called' id. This > sounds right - > I'd imagine that a privacy mechanism would use the RPID > header to express > the private identity of the sender of a message; and in fact, if the > rpi-id-type header is not present, that's exactly what the recipient > assumes. So in short the motivation for this parameter isn't > clear. If there > is a need for it then the draft should describe it, > otherwise, I think this > parameter should be removed, since the default behavior seems > appropriate. > This draft allows network-asserted identity as a means to > end-user privacy; > the identity that is private is the identity of the originator of the > message. Finally, if you are going to have this parameter > anyway, "calling" > and "called" are a little too telephony-specific, and those > telephony roles > don't map cleanly onto the mechanism. This is already causing > problems in > the draft: in 7.5, it suggests that you proxies should use > the "calling" > rpi-id-type to identify the originator of any INVITE request > - but what > about a re-INVITE in the reverse direction in the middle of a dialog? > > - rpi-id-type: I find this the most problematic of the > existing parameters. > I believe that the sip-privacy mechanism (at least, this > chartered work) > exists to make an identity private, not to invent new forms > of identity. I > believe that the kinds of entities in a SIP network that have privacy > concerns are users - not client devices, or intermediary > devices, or what > have you. Now, that isn't to say that keeping a user's > identity private > might not require hiding information about the device from > which a user is > calling, and so on. This does not, however, motivate a need for a > network-asserted device URI like the "term" value of the > rpi-id-type. No > proxy or UAS behavior is suggested in the document for use of > the "term" > rpi-id-type, nor is it made clear how a proxy inserting this > RPID would know > to assert an "identity" for a terminal (possibly from some out-of-band > authentication mechanism? but does the terminal authenticate > itself as well > as the user?). Also, the distinction between "user" and > "subscriber" in > privacy-04 is a little confusing. They represent a new > distinction between > identities in SIP, and it isn't particularly clear why they > are required as > part of a privacy mechanism; the difference between a > "subscriber" (the > default, and traditionally the user of the SIP session), and > a "user" seems > to be somehow related to settlement, or the administrative > grouping of user > accounts. It isn't clear how a proxy would ascertain that it > needs to apply > these parameters to an RPID, or how they'd be used So, I'd > also like to > suggest that if there is a need for a parameter or header > that can assert > arbitrary new types of identity (distinguishing between subscribers or > users, URIs for devices, secret superhero identities, etc), > then I for one > would like to see this proposed in a separate document. New types of > identity introduced to SIP may in turn have some privacy > requirements, but > it does not follow from this that a privacy document is the > right place to > propose all kinds of new identities. If these identities are > useful outside > the context of privacy, that might have suggested that this > is a separable > issue. The privacy considerations for these new identities > can be explored > subsequent to their acceptance by the SIP community. For the > time being, I > think this parameter is superfluous and confusing, and it > should be removed. > > - rpi-privacy: To me this parameter is really the crux of the > draft - that > and the fact that the RPID header can be added, deleted or > modified only by > proxy servers. However, it hasn't been clear to me why the > privacy parameter > is defined only within the scope of the RPID header. If we > would like this > draft to have general applicability to the privacy problem, > perhaps it would > be better if "privacy" were defined as a general URI header. > The RPID header > should usually, but perhaps not always, contain a URI that > has a "privacy" > parameter. I'd be interested to hear if there are scenarios within the > applicability of the draft in which the RPID header should be > used without a > "privacy" parameter - perhaps the presence of "privacy" in > RPID could be a > MUST. However, I see no reason why it might not make sense > for other URIs > than those in an RPID to contain the "privacy" parameter. > > - Extensibility: While it's generally desirable for a mechanism to be > extensible (you should reuse existing mechanisms to solve new > problems if > you can), sometimes extensibility can be confusing. Given the strict > applicability that precedes sip-privacy-04, it isn't really > clear how much > extensibility is desirable - and at what point extensibility > would invite > the use of RPID to architectures outside of that > applicability. While I > applaud the move in sip-privacy-04 to require that extensions > to the RPID be > published in an RFC, I'm not sure that this alone is > sufficient. The middle > two parameters I've discussed above (rpi-ip-type and rpi-pty-type) are > extensible in privacy-04. Given that I'm a little queasy on > their current > values (not to mention their overall relevance), it would probably go > without saying that I'm unsure about extending them further. These > reservations do not however carry over to the 'rpi-privacy' > parameter - I > believe that should be extensible. > > - RPID-Privacy: The need to assert any of the above parameters in the > RPID-Privacy should probably also be revisited in the light of the > considerations above. I think it's pretty clear that an > RPID-Privacy header > should express the wishes of the originating user to keep > their identity > private in this message, and it isn't clear why a user would > want to tell > the network to, say, keep some other user's identity private. > If this is > needed, the draft should explain when it would be useful. > > - Gobbledygook in From: The motivation for cryptographically > random garbage > in the From header may have gone away in light of the mandate > for the 'tag' > parameter in the From field of requests in rfc2543bis, which > guarantees that > dialog identification will be globally unique. I would > suggest instead that > the From header for an anonymous request should be completely > homogenous, so > all private From headers look alike. rfc2543bis09 actually > contains examples > of both - in some places, anonymous requests use an > apparently random user > and/or host, in other places something standard like > 'anonymous@localhost'. > I would recommend the latter, if only because you already > have to build > something globally unique for the tag - or at the very least, > that this > point be revisited in light of bis. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1D00E.D64C03B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] comments on privacy-04

Jon, all,

With respect to the charter & the privacy draft, = I guess we can argue which was chicken & which was egg. Both have = been as they are now for some time without comment.

I think, as discussed before WGLC, that extensibility = is important. When/if new identity types are required to be carried by = Remote-Party-ID, we can add these and be sure that the correct privacy = handing takes place at proxies which do not recognise the new identity = type. This would not be the case for new headers.

Also, I think RPID should be self-qualifying, in that = you should not have to look at the context (in terms of the individual = message) to determine to whom the identity applies. This makes things = simpler to understand and supports future re-use in other contexts. Any = text saying that implications should be drawn from the particular = message in which RPID appears, I think should be amended.

I agree completely with your desire to remove the = factors which cause people to put gobbledegook in From:/To:. A general = URI parameter as you suggest would allow 'private'(*) or 'potentially = private' (**) information to be passed to trusted proxies in From:/To: = by a UA. This may also remove the arguments for inserting RPID at an = untrusted UA.

This is supposing that the URI parameter MUST be = acted on by devices supporting the Proxy-Require: privacy tag. This in = turn implies a requirement for those devices to be able to route via = another device/function which can modify the From/To fields. [Let's not = argue now about what such a device is called :-)]

(*) By 'private' I mean that the information cannot = be passed to other UAs, but is required to be visible to (trusted) = network entities.

(**) Information inserted by the UAC may become = 'private' without the knowledge of the UAC due to the operation of = services in the network. Such 'potentially private' information cannot = presently be placed in From/To without a means of marking the privacy = status and modifying the information as described above.

Finally, regarding 'subscriber' and 'user', one = definition of these appears in the European Union Directive on = protection of privacy in telecommunications networks:

(a) 'subscriber` shall mean any natural or legal = person who or which is party to a contract with the provider of = publicly available telecommunications services for the supply of such = services;

(b) 'user` shall mean any natural person using a = publicly available telecommunications service, for private or business = purposes, without necessarily having subscribed to this = service;

(c) 'public telecommunications network` shall mean = transmission systems and, where applicable, switching equipment and = other resources which permit the conveyance of signals between defined = termination points by wire, by radio, by optical or by other = electromagnetic means, which are used, in whole or in part, for the = provision of publicly available telecommunications services;

(d) 'telecommunications service` shall mean services = whose provision consists wholly or partly in the transmission and = routing of signals on telecommunications networks, with the exception = of radio- and television broadcasting.

I think these terms are pretty much applicable to SIP = services, certainly within the realm of applicability of this privacy = draft. If people are not happy with the common sense meanings of the = terms, then we could include the above definitions.

Regards...Mark





> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: 18 March 2002 17:04
> To: 'sip@ietf.org'
> Subject: [Sip] comments on privacy-04
>
>
>
> Since we now have a WGLC on sip-privacy-04, I = have a couple
> of comments that
> I apologize in advance for not presenting = earlier.
>
> I think that SIP needs a network-provided = privacy mechanism,
> and I think the
> system described by this draft is a reasonable = solution to
> that problem.
> However, the sip-privacy-04 system is more = complicated than
> it needs to be
> in order to solve this problem, and these = complexities give rise to
> confusions about the implementation and = applicability of the
> mechanism.
> Today, the SIP charter speaks to a need for = privacy
> mechanisms but not, for
> example, for new identity-assertion = mechanisms.
>
> Jon Peterson
> NeuStar, Inc.
>
> -----
>
> - rpi-screen: As the recent thread in the SIP = ML suggested,
> the behavior in
> sip-privacy-04 for handling RPIDs received from = an untrusted
> source might be
> confusing. If untrusted entities shouldn't add = the RPID
> header (which I
> gather from the applicability), then why not = say that a proxy
> MUST remove
> any RPID headers it receives from an untrusted = source? Today,
> it sets the
> 'screen=3Dno' parameter instead. However, no = behavior in the document is
> defined for using an RPID header with = 'screen=3Dno' - it merely
> says that a UA
> that receives it in a message shouldn't trust = it (although what exact
> behavior this entails is unclear). If this is = totally deadweight in
> signaling, it should just be removed - SIP = messages don't
> need any help
> getting larger. If you receive a RPID from a = trusted entity,
> 'screen=3Dyes'
> could just be assumed; a parameter that says = "trust me" may
> very well be
> redundant in a trusted network. If it turns out = that an RPID
> that the proxy
> will add itself is identical to an RPID that = has been supplied by an
> untrusted source, then while this may be just = lip service I
> think the least
> ambiguous and most secure language is still to = say that the
> proxy removes
> the untrusted header and adds a trusted header. = If for
> whatever reason it
> turns out we do need this parameter, the idea = that both
> 'screen=3Dyes' and
> 'screen=3Dno' can appear in the same RPID = header (this is
> permitted in 6.1)
> must be unnecessary. Finally, if you are going = to have this parameter,
> calling it "screen" is a little = misleading; screening in the
> PSTN can refer
> to selectively blocking calls based on the = original
> calling/called number
> (to me it implies that some feature has been = invoked that
> inspects the ANI
> and the dialed number and determines that this = is a
> legitimate target for
> the caller's class of service). Maybe = "verify" would make more sense.
>
> - rpi-pty-type: This parameter allows you to = specify which
> party's identity
> is contained in the RPID header = ("calling" or "called" are currently
> allowed). However, no motivation for this = capability is
> presented in the
> draft - it defines the conditions under which = these
> parameters are inserted,
> but there is no recipient behavior that = justifies their
> insertion. Moreover,
> the behavior for adding the parameter holds = only that a
> request contains a
> 'calling' id, and the response contains a = 'called' id. This
> sounds right -
> I'd imagine that a privacy mechanism would use = the RPID
> header to express
> the private identity of the sender of a = message; and in fact, if the
> rpi-id-type header is not present, that's = exactly what the recipient
> assumes. So in short the motivation for this = parameter isn't
> clear. If there
> is a need for it then the draft should describe = it,
> otherwise, I think this
> parameter should be removed, since the default = behavior seems
> appropriate.
> This draft allows network-asserted identity as = a means to
> end-user privacy;
> the identity that is private is the identity of = the originator of the
> message. Finally, if you are going to have this = parameter
> anyway, "calling"
> and "called" are a little too = telephony-specific, and those
> telephony roles
> don't map cleanly onto the mechanism. This is = already causing
> problems in
> the draft: in 7.5, it suggests that you proxies = should use
> the "calling"
> rpi-id-type to identify the originator of any = INVITE request
> - but what
> about a re-INVITE in the reverse direction in = the middle of a dialog?
>
> - rpi-id-type: I find this the most problematic = of the
> existing parameters.
> I believe that the sip-privacy mechanism (at = least, this
> chartered work)
> exists to make an identity private, not to = invent new forms
> of identity. I
> believe that the kinds of entities in a SIP = network that have privacy
> concerns are users - not client devices, or = intermediary
> devices, or what
> have you. Now, that isn't to say that keeping a = user's
> identity private
> might not require hiding information about the = device from
> which a user is
> calling, and so on. This does not, however, = motivate a need for a
> network-asserted device URI like the = "term" value of the
> rpi-id-type. No
> proxy or UAS behavior is suggested in the = document for use of
> the "term"
> rpi-id-type, nor is it made clear how a proxy = inserting this
> RPID would know
> to assert an "identity" for a = terminal (possibly from some out-of-band
> authentication mechanism? but does the terminal = authenticate
> itself as well
> as the user?). Also, the distinction between = "user" and
> "subscriber" in
> privacy-04 is a little confusing. They = represent a new
> distinction between
> identities in SIP, and it isn't particularly = clear why they
> are required as
> part of a privacy mechanism; the difference = between a
> "subscriber" (the
> default, and traditionally the user of the SIP = session), and
> a "user" seems
> to be somehow related to settlement, or the = administrative
> grouping of user
> accounts. It isn't clear how a proxy would = ascertain that it
> needs to apply
> these parameters to an RPID, or how they'd be = used  So, I'd
> also like to
> suggest that if there is a need for a parameter = or header
> that can assert
> arbitrary new types of identity (distinguishing = between subscribers or
> users, URIs for devices, secret superhero = identities, etc),
> then I for one
> would like to see this proposed in a separate = document. New types of
> identity introduced to SIP may in turn have = some privacy
> requirements, but
> it does not follow from this that a privacy = document is the
> right place to
> propose all kinds of new identities. If these = identities are
> useful outside
> the context of privacy, that might have = suggested that this
> is a separable
> issue. The privacy considerations for these new = identities
> can be explored
> subsequent to their acceptance by the SIP = community. For the
> time being, I
> think this parameter is superfluous and = confusing, and it
> should be removed.
>
> - rpi-privacy: To me this parameter is really = the crux of the
> draft - that
> and the fact that the RPID header can be added, = deleted or
> modified only by
> proxy servers. However, it hasn't been clear to = me why the
> privacy parameter
> is defined only within the scope of the RPID = header. If we
> would like this
> draft to have general applicability to the = privacy problem,
> perhaps it would
> be better if "privacy" were defined = as a general URI header.
> The RPID header
> should usually, but perhaps not always, contain = a URI that
> has a "privacy"
> parameter. I'd be interested to hear if there = are scenarios within the
> applicability of the draft in which the RPID = header should be
> used without a
> "privacy" parameter - perhaps the = presence of "privacy" in
> RPID could be a
> MUST. However, I see no reason why it might not = make sense
> for other URIs
> than those in an RPID to contain the = "privacy" parameter.
>
> - Extensibility: While it's generally desirable = for a mechanism to be
> extensible (you should reuse existing = mechanisms to solve new
> problems if
> you can), sometimes extensibility can be = confusing. Given the strict
> applicability that precedes sip-privacy-04, it = isn't really
> clear how much
> extensibility is desirable - and at what point = extensibility
> would invite
> the use of RPID to architectures outside of = that
> applicability. While I
> applaud the move in sip-privacy-04 to require = that extensions
> to the RPID be
> published in an RFC, I'm not sure that this = alone is
> sufficient. The middle
> two parameters I've discussed above = (rpi-ip-type and rpi-pty-type) are
> extensible in privacy-04. Given that I'm a = little queasy on
> their current
> values (not to mention their overall = relevance), it would probably go
> without saying that I'm unsure about extending = them further. These
> reservations do not however carry over to the = 'rpi-privacy'
> parameter - I
> believe that should be extensible.
>
> - RPID-Privacy: The need to assert any of the = above parameters in the
> RPID-Privacy should probably also be revisited = in the light of the
> considerations above. I think it's pretty clear = that an
> RPID-Privacy header
> should express the wishes of the originating = user to keep
> their identity
> private in this message, and it isn't clear why = a user would
> want to tell
> the network to, say, keep some other user's = identity private.
> If this is
> needed, the draft should explain when it would = be useful.
>
> - Gobbledygook in From: The motivation for = cryptographically
> random garbage
> in the From header may have gone away in light = of the mandate
> for the 'tag'
> parameter in the From field of requests in = rfc2543bis, which
> guarantees that
> dialog identification will be globally unique. = I would
> suggest instead that
> the From header for an anonymous request should = be completely
> homogenous, so
> all private From headers look alike. = rfc2543bis09 actually
> contains examples
> of both - in some places, anonymous requests = use an
> apparently random user
> and/or host, in other places something standard = like
> 'anonymous@localhost'.
> I would recommend the latter, if only because = you already
> have to build
> something globally unique for the tag - or at = the very least,
> that this
> point be revisited in light of bis.
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1D00E.D64C03B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 09:33:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00489 for ; Wed, 20 Mar 2002 09:33:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17074 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 09:33:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15814; Wed, 20 Mar 2002 09:11:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15787 for ; Wed, 20 Mar 2002 09:11:29 -0500 (EST) Received: from accord-ntsrv3.accord-domain ([212.199.61.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29866 for ; Wed, 20 Mar 2002 09:11:25 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 16:11:07 +0200 Message-ID: From: "Even, Roni" To: "'Guntram Diehl'" , "'sip@ietf.org'" Subject: RE: [Sip] media coder negotiation Date: Wed, 20 Mar 2002 16:11:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, There is a simcap (simple capabilities) draft. It address some aspects of capabilities negotiations. There are also some difference between caps in H.323 and the definitions in SIP mostly for video Roni Even Polycom > -----Original Message----- > From: Guntram Diehl [mailto:gdiehl@innovaphone.com] > Sent: Wednesday, March 20, 2002 1:57 PM > To: 'sip@ietf.org' > Subject: [Sip] media coder negociation > > > Hi, > > can anybody tell me if there is already any work concerning > media coder > negociation within sip in progress? > > There seems to be a need for this for several reasons: > > - SIP - H.323 interworking > - RSVP: You have to make reservations with RSVP as receiver > of the media > stream. How can you make reservations if you don't know which > one of the > different sessions you annouce via SDP is used by the other side. > - Most of the available DSP software for coders support > symmetric coders > only. > > Guntram > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 11:02:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03332 for ; Wed, 20 Mar 2002 11:02:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22181 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 11:02:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19774; Wed, 20 Mar 2002 10:27:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19734 for ; Wed, 20 Mar 2002 10:27:27 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02221 for ; Wed, 20 Mar 2002 10:27:24 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2KFQrd18341; Wed, 20 Mar 2002 07:26:53 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA22791; Wed, 20 Mar 2002 07:26:52 -0800 (PST) Message-ID: <3C98AA34.A931D68C@cisco.com> Date: Wed, 20 Mar 2002 10:26:45 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruppelt Christian CC: sip@ietf.org Subject: Re: [Sip] question on privacy 04 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It can send back a 407 and ask the UAC to authenticate itself. Note that this is outside the scope of the privacy draft though. -- Flemming Ruppelt Christian wrote: > How could the Proxy-o determine the identity of UA-o (see basic privacy example)? > The From field (cryptographically random identifier, non identifying hostname) > could not be used for this. The Remote-Party-ID header is not sent by UA-o. > > regards > Christian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 11:08:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03516 for ; Wed, 20 Mar 2002 11:08:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22577 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 11:08:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19572; Wed, 20 Mar 2002 10:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19541 for ; Wed, 20 Mar 2002 10:23:47 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02143 for ; Wed, 20 Mar 2002 10:23:43 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2KFNDh04649; Wed, 20 Mar 2002 07:23:14 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA20943; Wed, 20 Mar 2002 07:22:55 -0800 (PST) Message-ID: <3C98256F.516534F7@cisco.com> Date: Wed, 20 Mar 2002 01:00:15 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule CC: "'Rohan Mahy'" , gonzalo.camarillo@ericsson.com, sip@ietf.org Subject: Re: [Sip] Reason header simplification References: <4DF5E8A771ECD21187020008C7B1C5AF0316C5B3@srvmail.cablelabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > Rohan wrote: > > Also I don't like to idea of sending ISUP (Q.850) or ISDN > > (Q.931) response > > codes around inside a SIP network. > Actually, I like that option a lot since mapping is almost never a one to one exercize when translating cause codes or release reason codes between protocols. True, but the idea with SIP is not to replicate ISUP or Q.931. I agree with Rohan here. Carrying "foreign" reason codes inside the SIP protocol itself is counter to the way we normally try to use SIP. The SIP-T framework is a good example of this and we should continue along those lines. > This is why some other protocols have also gone that route of "encapsulating" the q.850 codes inside release or release complete messages in order to have transparency. > > > I'd rather use standard > > ISUP-SIP or > > ISDN-SIP cause code translation, so that an ordinary SIP UA > > can just use a set of well-defined SIP cause codes. > The requirement expressed here is something like "whenever possible, a SIP cause code should also be provided". The reason header draft could clarify the rules of dealing with multiple reason header lines (we could have q.850 reason codes carried for end-to-end purposes or other H.323/SIP inter-working functions but still mandate a sip reason header line for the signaling hops along the sip chain). If this information is only for non-SIP end-systems, then why does it have to be in a SIP header ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 11:08:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03552 for ; Wed, 20 Mar 2002 11:08:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22609 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 11:08:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20895; Wed, 20 Mar 2002 10:41:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20842 for ; Wed, 20 Mar 2002 10:41:38 -0500 (EST) Received: from web20604.mail.yahoo.com (web20604.mail.yahoo.com [216.136.226.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02659 for ; Wed, 20 Mar 2002 10:41:34 -0500 (EST) Message-ID: <20020320154130.52276.qmail@web20604.mail.yahoo.com> Received: from [166.63.187.71] by web20604.mail.yahoo.com via HTTP; Wed, 20 Mar 2002 07:41:30 PST Date: Wed, 20 Mar 2002 07:41:30 -0800 (PST) From: Vijay Gurbani Subject: Re: [Sip] Requirements on Reason information. New I-D To: seancolson@yahoo.com Cc: Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org, spirits@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sean Olson wrote: >This is a very slippery slope. Although it is >just as problematic, I would prefer the use of >the Server: header for this task. The less the >PSTN pollutes the SIP protocol, the better. Sean: In principal, I agree with you a 100%. However, reality is that for better or for worse, in the near tearm, SIP will have accomodate other networks. Usage of the Reason header in conjunction with interworking with foreign networks is sufficiently "off the beaten" path so that folks implementing baseline SIP do not have to worry about it if they do not want to. In any case, I do not want to start a war on the merits or demerits of SIP interworking with other protocols; just want to point out that the Reason header could be used successfully in those cases. Regards, - vijay ===== - vijay -- Vijay K. Gurbani vgurbani@yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 11:15:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03746 for ; Wed, 20 Mar 2002 11:15:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22936 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 11:15:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21240; Wed, 20 Mar 2002 10:50:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21211 for ; Wed, 20 Mar 2002 10:50:14 -0500 (EST) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02857 for ; Wed, 20 Mar 2002 10:50:11 -0500 (EST) Message-ID: <20020320155013.94640.qmail@web11605.mail.yahoo.com> Received: from [166.63.189.85] by web11605.mail.yahoo.com via HTTP; Wed, 20 Mar 2002 07:50:13 PST Date: Wed, 20 Mar 2002 07:50:13 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Requirements on Reason information. New I-D To: Vijay Gurbani Cc: Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org, spirits@lists.bell-labs.com In-Reply-To: <20020320154130.52276.qmail@web20604.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I understand the problem you want to solve. I have no issue with interworking with other networks. My main issue is attempting to *identify* the network you are interworking with via the Reason: header. This is the slippery slope I want to avoid. It quickly becomes very nasty in more complex topologies where you may dip into the PSTN-space more than once. /sean --- Vijay Gurbani wrote: > Sean Olson wrote: > >This is a very slippery slope. Although it is > >just as problematic, I would prefer the use of > >the Server: header for this task. The less the > >PSTN pollutes the SIP protocol, the better. > > Sean: > > In principal, I agree with you a 100%. However, > reality is that for better or for worse, in the near > tearm, SIP will have accomodate other networks. > > Usage of the Reason header in conjunction with > interworking with foreign networks is sufficiently > "off the beaten" path so that folks implementing > baseline SIP do not have to worry about it if they > do > not want to. > > In any case, I do not want to start a war on the > merits or demerits of SIP interworking with other > protocols; just want to point out that the Reason > header could be used successfully in those cases. > > Regards, > > - vijay > > > ===== > - vijay > -- > Vijay K. Gurbani > vgurbani@yahoo.com > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 12:04:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05704 for ; Wed, 20 Mar 2002 12:04:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27579 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 12:04:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24106; Wed, 20 Mar 2002 11:34:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24075 for ; Wed, 20 Mar 2002 11:33:57 -0500 (EST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04272 for ; Wed, 20 Mar 2002 11:33:52 -0500 (EST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA24996; Wed, 20 Mar 2002 17:33:52 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA27018; Wed, 20 Mar 2002 17:33:38 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 17:34:15 +0100 Message-ID: From: Ruppelt Christian To: "'Flemming Andreasen'" Cc: sip@ietf.org Subject: AW: [Sip] question on privacy 04 Date: Wed, 20 Mar 2002 17:34:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA24076 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit The text in 7.1 Untrusted UAC Behavior says: ... and the UAC wants to control the privacy for any Remote-Party-ID ... by a downstream proxy. Each of these RPID-privacy headers ... to maintain privacy of the "addr-spec" My question is: where does this "addr-spec" come from? The proxy needs it to add a corresponding Remote-Party-ID. Could this be outside the scope of the draft? Christian -----Urspr�ngliche Nachricht----- Von: Flemming Andreasen [mailto:fandreas@cisco.com] Gesendet: Mittwoch, 20. M�rz 2002 16:27 An: Ruppelt Christian Cc: sip@ietf.org Betreff: Re: [Sip] question on privacy 04 It can send back a 407 and ask the UAC to authenticate itself. Note that this is outside the scope of the privacy draft though. -- Flemming Ruppelt Christian wrote: > How could the Proxy-o determine the identity of UA-o (see basic privacy example)? > The From field (cryptographically random identifier, non identifying hostname) > could not be used for this. The Remote-Party-ID header is not sent by UA-o. > > regards > Christian > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 12:04:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05720 for ; Wed, 20 Mar 2002 12:04:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27598 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 12:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24884; Wed, 20 Mar 2002 11:48:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24852 for ; Wed, 20 Mar 2002 11:48:11 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04913 for ; Wed, 20 Mar 2002 11:48:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2KGmUTE011742; Wed, 20 Mar 2002 11:48:31 -0500 (EST) Message-ID: <3C98BD1D.5D4FC416@dynamicsoft.com> Date: Wed, 20 Mar 2002 11:47:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Guntram Diehl CC: "'sip@ietf.org'" Subject: Re: [Sip] media coder negociation References: <1921644655FE154BB2381C086C4FD8E305187E@kaula.innovaphone.int> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The offer/answer model of SDP allows for an agreeement on the set of codecs that are used in the session. Please see: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-02.txt -Jonathan R. Guntram Diehl wrote: > > Hi, > > can anybody tell me if there is already any work concerning media coder > negociation within sip in progress? > > There seems to be a need for this for several reasons: > > - SIP - H.323 interworking > - RSVP: You have to make reservations with RSVP as receiver of the media > stream. How can you make reservations if you don't know which one of the > different sessions you annouce via SDP is used by the other side. > - Most of the available DSP software for coders support symmetric coders > only. > > Guntram > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Wed Mar 20 12:10:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05963 for ; Wed, 20 Mar 2002 12:10:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27921 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 12:10:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25375; Wed, 20 Mar 2002 11:56:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25340 for ; Wed, 20 Mar 2002 11:56:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05229 for ; Wed, 20 Mar 2002 11:56:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2KGuUTE011773; Wed, 20 Mar 2002 11:56:31 -0500 (EST) Message-ID: <3C98BEFD.F9922184@dynamicsoft.com> Date: Wed, 20 Mar 2002 11:55:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Jansson CC: sip@ietf.org Subject: Re: [Sip] bis-09 references non existing definition. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Jansson wrote: > > 17.2.3 Matching Requests to Server Transactions, line 3520: > "Matching is done based on the matching rules defined for > each of those header fields." > > But there is no matching rule defined for the Via header. > Maybe there should be one. Right, thats an omission. However, its a fairly obvious matching rule, which is that all fields in each need to match. We'll log it for later handling, whatever we decide to do. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Wed Mar 20 12:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06050 for ; Wed, 20 Mar 2002 12:13:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28048 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 12:13:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25479; Wed, 20 Mar 2002 11:59:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25454 for ; Wed, 20 Mar 2002 11:59:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05293 for ; Wed, 20 Mar 2002 11:59:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2KGxoTE011782; Wed, 20 Mar 2002 11:59:51 -0500 (EST) Message-ID: <3C98BFC5.56A1D625@dynamicsoft.com> Date: Wed, 20 Mar 2002 11:58:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fuxbruner, Amihay" CC: sip@ietf.org Subject: Re: [Sip] Question on CANCEL - backwards-compatibility References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Fuxbruner, Amihay" wrote: > > Hi, > > Early bis drafts support CANCEL for any request. > How UAS (bis 09) should respond to CANCEL for none-INVITE request from > UAC (early bis) ? > Send a 200 OK and do nothing else. This is discussed in the final paragraph of 9.2 of bis, which reads: Regardless of the method of the original request, as long as the CANCEL matched an existing transac- tion, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed 1501 following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL 1502 and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is 1503 passed to the server transaction for transmission. 1504 -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (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 daemon@optimus.ietf.org Wed Mar 20 12:41:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07225 for ; Wed, 20 Mar 2002 12:41:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29829 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 12:41:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28583; Wed, 20 Mar 2002 12:23:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28552 for ; Wed, 20 Mar 2002 12:23:35 -0500 (EST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06506 for ; Wed, 20 Mar 2002 12:23:29 -0500 (EST) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.10.1/8.10.1) with ESMTP id g2KHMtb08747; Wed, 20 Mar 2002 10:22:55 -0700 (MST) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 10:22:55 -0700 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF0316C5C8@srvmail.cablelabs.com> From: Jean-Francois Mule To: "'Flemming Andreasen'" Cc: sip@ietf.org Subject: RE: [Sip] Reason header simplification Date: Wed, 20 Mar 2002 10:22:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Flemming Andreasen wrote: > > > Also I don't like to idea of sending ISUP (Q.850) or ISDN > > > (Q.931) response > > > codes around inside a SIP network. If i am correct, q.850 does address cause codes for both ss7 isup and q.931 (dss1/isdn). > True, but the idea with SIP is not to replicate ISUP or > Q.931. we all agree here and let's not mud the water. The question is more general than "foreign" pstn networks! How do you deal with instant messaging reason codes and the "not at home" reason for e.g.? I would rather see this reason header be used and extended with adequate namespaces for other protocols rather than have to slap all the non "pure" sip reason codes inside bodies. > I agree with Rohan here. Carrying "foreign" reason > codes inside the SIP protocol itself is counter to the way we > normally try to use SIP. The SIP-T framework is a good > example of this and we should continue along those lines. fine with me but again, why not create a more general reason header. > If this information is only for non-SIP end-systems, then why > does it have to be in a SIP header ? good point, there are some sip end-systems that could use other protocols reason codes too. Jean-Francois. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 17:25:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17481 for ; Wed, 20 Mar 2002 17:25:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18807 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 17:25:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17354; Wed, 20 Mar 2002 17:05:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13955 for ; Wed, 20 Mar 2002 16:08:31 -0500 (EST) Received: from hotmail.com (f28.law7.hotmail.com [216.33.237.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15043 for ; Wed, 20 Mar 2002 16:08:28 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Mar 2002 13:07:56 -0800 Received: from 166.63.187.203 by lw7fd.law7.hotmail.msn.com with HTTP; Wed, 20 Mar 2002 21:07:55 GMT X-Originating-IP: [166.63.187.203] From: "Sriramp Parameswar" To: sip@ietf.org Date: Wed, 20 Mar 2002 21:07:55 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 20 Mar 2002 21:07:56.0226 (UTC) FILETIME=[4E93DA20:01C1D053] Subject: [Sip] REFER Security Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org
Hi:
 
I tend to fall into the camp that believes when you have any intermediary you weaken security - also I am queasy about self signed certificates.
 
I would put my vote clearly behind C (transfer target from cc-transfer) directly contacts A (transferor in cc-transfer) and asking for verification. This was shown as VERIFY in Roberts slides - and may I suggest that we use NEGOTIATE as the method that does this verification check.
 
Thanks,
 
Sriram

Join the world뭩 largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 17:27:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17553 for ; Wed, 20 Mar 2002 17:27:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA18920 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 17:27:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17665; Wed, 20 Mar 2002 17:10:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17630 for ; Wed, 20 Mar 2002 17:10:24 -0500 (EST) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16854 for ; Wed, 20 Mar 2002 17:10:21 -0500 (EST) Message-ID: <20020320221024.31411.qmail@web11604.mail.yahoo.com> Received: from [166.63.189.85] by web11604.mail.yahoo.com via HTTP; Wed, 20 Mar 2002 14:10:24 PST Date: Wed, 20 Mar 2002 14:10:24 -0800 (PST) From: Sean Olson To: jdrosen@dynamicsoft.com, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Version Info in Watcher Info Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I was curious why the version/id used for deltas is part of the watcher element and not the top level watcherinfo element. Is this to allow for simpler aggregation? /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 18:38:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19169 for ; Wed, 20 Mar 2002 18:38:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA22812 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 18:38:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21824; Wed, 20 Mar 2002 18:22:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA21794 for ; Wed, 20 Mar 2002 18:22:25 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18765 for ; Wed, 20 Mar 2002 18:22:21 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2KNKsD09040 for ; Wed, 20 Mar 2002 18:20:54 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2KNKsG09034 for ; Wed, 20 Mar 2002 18:20:54 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D066.2EAA7850" Subject: RE: [Sip] REFER Security Date: Wed, 20 Mar 2002 16:23:03 -0700 Message-ID: Thread-Topic: [Sip] REFER Security Thread-Index: AcHQXVOAbAL+i9HUSMyLTEdz5va4uwACKZnA From: "Zmolek, Andrew (Andrew)" To: "Sriramp Parameswar" , Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D066.2EAA7850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are you suggesting that security trumps privacy in this case? =20 --Andy -----Original Message----- From: Sriramp Parameswar [mailto:sriramkp@hotmail.com] Sent: Wednesday, March 20, 2002 2:08 PM To: sip@ietf.org Subject: [Sip] REFER Security Hi: =20 I tend to fall into the camp that believes when you have any = intermediary you weaken security - also I am queasy about self signed = certificates. =20 I would put my vote clearly behind C (transfer target from cc-transfer) = directly contacts A (transferor in cc-transfer) and asking for = verification. This was shown as VERIFY in Roberts slides - and may I = suggest that we use NEGOTIATE as the method that does this verification = check. =20 Thanks, =20 Sriram _____ =20 Join the world's largest e-mail service with MSN Hotmail. Click = Here _______________________________________________ Sip mailing list = https://www1.ietf.org/mailman/listinfo/sip This list is for NEW = development of the core SIP Protocol Use = sip-implementors@cs.columbia.edu for questions on current sip Use = sipping@ietf.org for new developments on the application of sip=20 ------_=_NextPart_001_01C1D066.2EAA7850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are=20 you suggesting that security trumps privacy in this = case?
 
--Andy
-----Original Message-----
From: Sriramp Parameswar = [mailto:sriramkp@hotmail.com]
Sent: Wednesday, March 20, = 2002 2:08=20 PM
To: sip@ietf.org
Subject: [Sip] REFER=20 Security

Hi:
 
I tend to fall into the camp that believes when you have any = intermediary=20 you weaken security - also I am queasy about self signed = certificates.
 
I would put my vote clearly behind C (transfer target from = cc-transfer)=20 directly contacts A (transferor in cc-transfer) and asking for = verification.=20 This was shown as VERIFY in Roberts slides - and may I suggest that we = use=20 NEGOTIATE as the method that does this verification check.
 
Thanks,
 
Sriram

Join the world's largest e-mail service with MSN Hotmail. Click=20 Here
_______________________________________________ Sip = mailing list=20 https://www1.ietf.org/mailman/listinfo/sip This list is for NEW = development of=20 the core SIP Protocol Use sip-implementors@cs.columbia.edu for = questions on=20 current sip Use sipping@ietf.org for new developments on the = application of=20 sip
------_=_NextPart_001_01C1D066.2EAA7850-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 18:59:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19621 for ; Wed, 20 Mar 2002 18:59:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA23509 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 18:59:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22626; Wed, 20 Mar 2002 18:32:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22594 for ; Wed, 20 Mar 2002 18:32:53 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18994 for ; Wed, 20 Mar 2002 18:32:47 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 18:32:20 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46A961A2@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: sip@ietf.org Date: Wed, 20 Mar 2002 18:32:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Manyfolks Clarifications Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Gonzalo, The reason behind stating the examples was to expose the flaws in the e2e v local/remote tags...so some additional discussion needed. Firstly, an obvious statement is that all preconditions must be e2e because the unavailability of resources at any point in the path damages the end to end flow. The SIP layer is the only layer that can be assumed to go end to end and is hence why precondition processing should be at the SIP layer.. we agree to that I assume.. Secondly, a less obvious statement is that all QoS protocols are segment by segment because even if the QoS protocols themselves go end to end, resources are only granted hop by hop and segment by segment based on local policy checks and agreement to allow the QoS protocol to interact with the network layer schedulers and undergo admission control. The UA doesn't know any of this and must not / cannot treat end to end signalling as some kind of magic...For example I can have a diff-serv SLA with a specific destination that is as strong a guarantee as any end to end protocol. RSVP for example can go one hop only from the host at both ends over their access links. Alternatively it can go end to end but bypass and not interact with any of the routers on the path. It can go end to end but only interact on one half of the path or finally it can go end to end and interact with all routers. The UA either sees RSVP end to end, RSVP over part of the path, with in either case the possibility of a non-RSVP cloud over an unknown portion of the RSVP path. The UA cannot know any of this and in fact doesn't even know the whereabouts of the SIP endpoint until SIP routing is completed. It cannot discover the non-RSVP cloud until feedback has been given and it never knows the impact of that cloud because it cannot know whether the non-RSVP cloud is a black hole or a dimensioned diff-serv cloud. The only thing the UA knows is whether its SLA supports SIP multimedia to specific prefixes. One potential way out of this mess might be to refer back to your clear statement below of when the UA can use the e2e tag. I believe I can interpret your statement to mean 'if the caller has a QoS SLA that covers the callee, independent of how that SLA is invoked in the form of network resources, then it can add the e2e tag'. Even then though, the callee prefix is not known until the response is received at the caller and so the caller can never safely add the e2e tag in the Invite. The callee can of course add it on receiving the Invite. The above discussion therefore suggests to me that all preconditions must be assumed to be end to end, that the e2e tag for the QoS mechanism is useless because it can never be safely applied, and therefore that the e2e tag be removed. All QoS mechanisms should be assumed to be segment by segment and we need to have tag names defined in the preconditions signalling to exchange who can, and agree who should, do the resource booking. This gives maximum isolation from the actual QoS mechanisms. The local/remote model is on the right path but I believe incomplete. Essentially, the model should be that the MN has an SLA wrt QoS with some limited scope (on-net, offnet to specific prefixes etc). The caller seeking preconditions simply adds in the Invite that that is the case, and will clearly only do so if believes it has a candidate SLA at its end. The preconditions therefore are automatically a request to see if the other end also has an SLA with its provider in the directions requested. How those SLA resources are accessed is in principle out of scope except that one end might have the SLA to allow resources to be accessed (the policy bit) but that resources need to be booked by the other end, such as in the case of RSVP. We therefore need a supplementary tag to indicate this requirement. When the callee/caller sees this supplementary tag it can either act on that request if it knows how to (configuration, experience, trial and error or mechanism specific tags) or it can refuse because it is either incapable, or unwilling to act on the other ends behalf. This is perfectly reasonably because if a MN has an SLA for SIP QoS to specific prefixes, then it is reasonable to expect that the operators have arranged for those resources to be accessable by including information of which mechanisms to use for each prefix. If these have not been arranged then the UAs must assume the preconditions cannot be met, but the UAs should still be able to reduce their preconditions to attempt a best effort call in these circumstances if they so desire. Note here that one reason a capable UA might refuse to remotely book the resources is because the person who books might be the one who is charged so a caller could in effect be asking for a reverse charge stream which a callee must be able to legitimately refuse. A related issue that I would like to raise is that given that the actual IP prefix of the callee is not known at the time of the offer (and hence the caller neither actually knows if it does have an SLA or a QoS mech for that callee prefix), it is critical that the preconditons be able to be flexibly adjusted in response to additional information. I would therefore suggest that preconditions should be able to be increased or decreased at either end, and not just increased. Non-logical increases and decreases should not be allowed though to avoid 'hunting'. The aim should be to 'converge' on an agreed precondition once the endpoints are identified and SLAs, QoS mechs and available resources confirmed. The precise rules will need some work though. The one remaining addition for this architecture in my opinion is to try to find a way to automate the discovery of what preconditions are possible to specific destinations and to increase the segment granularity of the QoS SLAs. This can only be done at the SIP layer and requires additional SIP smarts. I have already done some work on this and will write it up in a draft in a couple of months time once present load is out of the way. I think this can be cleanly separated from the manyfolks draft which essentially only deals with two local arbitrarily sized access segments that only provide end to end guarantees if the segments overlap or at least meet at a common edge... Hope this takes us forward Gonzalo... -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 20 March 2002 04:48 To: Alan O'Neill Cc: sip@ietf.org Subject: Re: Manyfolks Clarifications Hello Alan, > Ideally, the aim is that preconditions, whilst trying to couple SDP > with QoS mechanisms, is independent of those mechanisms. Yes, that's the idea. > However, with the > two choices available to the UA (e2e or local/remote) status types the draft > needs to be very clear about the state and rules used by a UA in inserting > those status tags. The rule is: if you have a way of knowing that there is end to end QoS, you can use e2e. Otherwise you would never know whether there is actually e2e QoS or not. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 20 23:50:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26143 for ; Wed, 20 Mar 2002 23:50:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA05490 for sip-archive@odin.ietf.org; Wed, 20 Mar 2002 23:50:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04581; Wed, 20 Mar 2002 23:28:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04550 for ; Wed, 20 Mar 2002 23:27:55 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25399 for ; Wed, 20 Mar 2002 23:27:52 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2L4Rpl04056; Wed, 20 Mar 2002 22:27:51 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2L4Rpu07860; Wed, 20 Mar 2002 22:27:51 -0600 (CST) Received: from lmf.ericsson.se (rmt160105.am.ericsson.se [138.85.160.105]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA14357; Wed, 20 Mar 2002 22:27:49 -0600 (CST) Message-ID: <3C9961F2.650FFE77@lmf.ericsson.se> Date: Thu, 21 Mar 2002 06:30:42 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, what do you want to put in the offer-2 to be sent that you cannot put in the answer-1? Understanding the scenario you have in mind would be helpful... Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Thank you for your answer > You are right, but sending a held SDP does not prevent the calling party to > start resource reservation, but only to send media. > I agree with you that normally, a port number to zero indicates refusal of > the media stream. Nevertheless, according to Offer/Answer draft, all port > numbers equal to zero is used also to announce capabilities (section 9), > and very often it is used to say just "don't use this media". > > What I need here is to give to the answerer the possibility to say "Mr.the > Offerer, I'm not rejecting your Invite, but I'd like to send you a new > offer right now, so it is useless to start resource reservation before > receiving this new offer" > > Best regards > Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 00:19:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26589 for ; Thu, 21 Mar 2002 00:19:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06913 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 00:19:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05602; Wed, 20 Mar 2002 23:53:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05575 for ; Wed, 20 Mar 2002 23:53:47 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26221 for ; Wed, 20 Mar 2002 23:53:43 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2L4rkl08140; Wed, 20 Mar 2002 22:53:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2L4rjQ04800; Wed, 20 Mar 2002 22:53:45 -0600 (CST) Received: from lmf.ericsson.se (rmt160105.am.ericsson.se [138.85.160.105]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA16332; Wed, 20 Mar 2002 22:53:44 -0600 (CST) Message-ID: <3C996804.906E2883@lmf.ericsson.se> Date: Thu, 21 Mar 2002 06:56:36 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: sip@ietf.org References: <8C92E23A3E87FB479988285F9E22BE46A961A2@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks Clarifications Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Alan O'Neill wrote: > The above discussion therefore suggests to me that all preconditions must be > assumed to be end to end, that the e2e tag for the QoS mechanism is useless > because it can never be safely applied, and therefore that the e2e tag be > removed. Look at the DCS architecture. They can besure when they have e2e QoS resources. And in my intranet, when my QoS reservation protocol tells me that I have e2e QoS service, it is because I have it. If you think that having e2e QoS is impossible, you should provide feedback to a different WG. Not SIP. > The local/remote model is on the right path but I believe incomplete. > Essentially, the model should be that the MN has an SLA wrt QoS with some > limited scope (on-net, offnet to specific prefixes etc). The caller seeking > preconditions simply adds in the Invite that that is the case, and will > clearly only do so if believes it has a candidate SLA at its end. Look at the 3GPP architecture. They have enough resources in the backbone. The only thing that worries them is the radio interface. With the local and remote tags they perform PDP context activation... it works. >but the UAs should still be able to reduce > their preconditions to attempt a best effort call in these circumstances if > they so desire. This is always possible. > A related issue that I would like to raise is that given that the actual IP > prefix of the callee is not known at the time of the offer (and hence the > caller neither actually knows if it does have an SLA or a QoS mech for that > callee prefix), it is critical that the preconditons be able to be flexibly > adjusted in response to additional information. That's why you have the carry the current status in the SDP. Because once you receive the first answer you can update it (because you know the destination IP address)... and if you required e2e QoS and after getting the remote IP address you notice that it is impossible, you do not want to establish the session, because your requirement cannot be fulfilled. If you want, you can send a new offer without preconditions, but the first offer/asnwer fails correctly, because your preconditions could not be met. > I would therefore suggest > that preconditions should be able to be increased or decreased at either > end, and not just increased. You can always send new offers. The only place where you can only upgrade the strength tag is within a single offer/answer exchange. Thanks for your comments, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 05:15:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08062 for ; Thu, 21 Mar 2002 05:15:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29826 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 05:15:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28640; Thu, 21 Mar 2002 04:46:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28609 for ; Thu, 21 Mar 2002 04:46:21 -0500 (EST) Received: from blaze.hcltech.com ([203.199.199.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07831 for ; Thu, 21 Mar 2002 04:46:17 -0500 (EST) Received: from suryapc ([192.168.201.166]) by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id PAA19715 for ; Thu, 21 Mar 2002 15:37:03 +0530 Message-ID: <01f201c1d0bc$a1fd0fb0$a6c9a8c0@suryapc> From: "Surya Kumar IVG" To: Date: Thu, 21 Mar 2002 15:11:53 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01EE_01C1D0EA.BBAA9D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Sip] SIP RFC -reg Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01EE_01C1D0EA.BBAA9D50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01EF_01C1D0EA.BBAA9D50" ------=_NextPart_001_01EF_01C1D0EA.BBAA9D50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 May i know, when RFC for SIP, is going to be released? regards surya ------=_NextPart_001_01EF_01C1D0EA.BBAA9D50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
May i know, when RFC for SIP, is going = to be=20 released?
 
 
 
regards
surya
------=_NextPart_001_01EF_01C1D0EA.BBAA9D50-- ------=_NextPart_000_01EE_01C1D0EA.BBAA9D50 Content-Type: text/x-vcard; name="surya kumar.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="surya kumar.vcf" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:kumar;surya FN:surya kumar ORG:HCL Technologies Ltd;Network Systems Lab TITLE:PM TEL;WORK;VOICE:Tel:91-44-2334174/81/2344209/2344241 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;CRM centre;51 JN = Road=3D0D=3D0AEkkaduthangal=3D0D=3D0AGuindy = =3D0D=3D0A;Chennai;TN;6000=3D 97;INDIA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:CRM centre=3D0D=3D0A51 JN = Road=3D0D=3D0AEkkaduthangal=3D0D=3D0AGuindy = =3D0D=3D0A=3D0D=3D0AChenna=3D i, TN 600097=3D0D=3D0AINDIA EMAIL;PREF;INTERNET:surya@netlab.hcltech.com REV:20020321T094153Z END:VCARD ------=_NextPart_000_01EE_01C1D0EA.BBAA9D50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 05:25:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08155 for ; Thu, 21 Mar 2002 05:25:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00106 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 05:25:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29579; Thu, 21 Mar 2002 05:05:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29548 for ; Thu, 21 Mar 2002 05:05:13 -0500 (EST) Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07979 for ; Thu, 21 Mar 2002 05:05:05 -0500 (EST) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.icomverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g2L9uP223225; Thu, 21 Mar 2002 11:56:27 +0200 Received: by il-tlv-mbdg1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Mar 2002 12:04:42 +0200 Message-ID: From: "Fuxbruner, Amihay" To: "'Jonathan Rosenberg'" , "'Ulrich Prakash'" Cc: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: RE: [Sip] [Sip-implementors] Question on CANCEL - backwards-compa tibility Date: Thu, 21 Mar 2002 12:04:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0BF.D1765A50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D0BF.D1765A50 Content-Type: text/plain; charset="iso-8859-1" Does sending 200 OK is the formal meaning of no-op ? Amihay Fuxbruner System Engineering - Signaling R&D Comverse -----Original Message----- From: Ulrich Prakash [mailto:uprakash@netlab.hcltech.com] Sent: Wednesday, March 20, 2002 9:46 PM To: Fuxbruner, Amihay; sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] Question on CANCEL - backwards-compatibility Hi, please refer the following text from the draft. Section 9.2 of bis-09, line 1497: If the original request was an INVITE,the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). The behavior upon reception of a CANCEL request for any other method defined in this specification is effectively no-op. Hence it should be a No operation. Thanks, Prakash. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, March 20, 2002 6:59 PM To: Fuxbruner, Amihay Cc: sip@ietf.org Subject: Re: [Sip] Question on CANCEL - backwards-compatibility "Fuxbruner, Amihay" wrote: > > Hi, > > Early bis drafts support CANCEL for any request. > How UAS (bis 09) should respond to CANCEL for none-INVITE request from > UAC (early bis) ? > Send a 200 OK and do nothing else. This is discussed in the final paragraph of 9.2 of bis, which reads: Regardless of the method of the original request, as long as the CANCEL matched an existing transac- tion, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed 1501 following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL 1502 and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is 1503 passed to the server transaction for transmission. 1504 -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com ------_=_NextPart_001_01C1D0BF.D1765A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] [Sip-implementors] Question on CANCEL - = backwards-compatibility

Does sending 200 OK is the formal meaning of no-op = ?


Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

-----Original Message-----
From: Ulrich Prakash [mailto:uprakash@netlab.hclte= ch.com]
Sent: Wednesday, March 20, 2002 9:46 PM
To: Fuxbruner, Amihay; = sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Question on CANCEL - = backwards-compatibility


Hi,

please refer the following text from the = draft.

Section 9.2 of bis-09, line 1497:
If the original request was an INVITE,the UAS SHOULD = immediately respond to the INVITE with a 487 (Request Terminated). =

The behavior upon reception of a CANCEL request for = any other method defined in this specification is effectively no-op. =

Hence it should be a No operation.

Thanks,
Prakash.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, March 20, 2002 6:59 PM
To: Fuxbruner, Amihay
Cc: sip@ietf.org
Subject: Re: [Sip] Question on CANCEL - = backwards-compatibility




"Fuxbruner, Amihay" wrote:
>
> Hi,
>
> Early bis drafts support CANCEL for any = request.
> How UAS (bis 09) should respond to CANCEL for = none-INVITE request from
> UAC (early bis) ?
>

Send a 200 OK and do nothing else. This is discussed = in the final
paragraph of 9.2 of bis, which reads:

Regardless of the method of the original request, as = long as the CANCEL
matched an existing transac- tion, the UAS answers = the CANCEL request
itself with a 200 (OK) response. This response is = constructed 1501
following the procedures described in Section 8.2.6 = noting that the To
tag of the response to the CANCEL 1502
and the To tag in the response to the original = request SHOULD be the
same. The response to CANCEL is 1503
passed to the server transaction for transmission. = 1504



-Jonathan R.

--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ = 07936
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com

------_=_NextPart_001_01C1D0BF.D1765A50-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 05:36:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08322 for ; Thu, 21 Mar 2002 05:36:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01059 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 05:36:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29943; Thu, 21 Mar 2002 05:18:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29893 for ; Thu, 21 Mar 2002 05:18:27 -0500 (EST) Received: from ws9.cdotb.ernet.in ([202.41.72.121]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08105 for ; Thu, 21 Mar 2002 05:18:21 -0500 (EST) Received: from jnana.cdotb.ernet.in (jnana.cdotb.ernet.in [192.168.51.201]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id PAA08497 for ; Thu, 21 Mar 2002 15:33:05 +0500 (GMT+0500) Received: from cdotb.ernet.in by jnana.cdotb.ernet.in (8.8.8/1.1.22.3/07Sep01-0156PM) id PAA0000024036; Thu, 21 Mar 2002 15:36:07 +0500 (GMT+0500) Message-ID: <3C99B178.9F0A7970@cdotb.ernet.in> Date: Thu, 21 Mar 2002 15:40:00 +0530 From: Titty Thomas Reply-To: titty@cdotb.ernet.in Organization: Centre for Development of Telematics X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/alternative; boundary="------------F35E60F6584A47937CA3B917" Subject: [Sip] Matching request/responses to transactions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------F35E60F6584A47937CA3B917 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a couple of queries on matching requests/responses to server/client transactions. As per sec 17.1.3 and 17.2.3 for finding the transaction handlers, comparisons of From, Call-ID, CSeq, Via, To and Request-URI headers are required. 1. Why comparisons of so many headers are required to figure out the cleint/server transaction? 2. Cant we do it with only Call-ID and CSeq header as this form a unique pair? If this was already discussed in the list, pointers to that will be very helpful. TIA, -- Titty -- Two roads diverged in a wood, and I took the one less traveled by, And that has made all the difference. --------------F35E60F6584A47937CA3B917 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

        I have a couple of queries on matching requests/responses to server/client transactions.

        As per sec 17.1.3 and 17.2.3  for finding the transaction handlers, comparisons of
        From, Call-ID, CSeq, Via, To and Request-URI headers are required.

        1. Why comparisons of so many headers are required to figure out the cleint/server transaction?

        2. Cant we do it with only Call-ID and CSeq header as this form a unique pair?

        If this was already discussed in the list, pointers to that  will be very helpful.

TIA,
-- Titty 

-- 
Two roads diverged in a wood, and I took the one less traveled by,
And that has made all the difference.
  --------------F35E60F6584A47937CA3B917-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 07:35:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09518 for ; Thu, 21 Mar 2002 07:35:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06339 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 07:35:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05426; Thu, 21 Mar 2002 07:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05397 for ; Thu, 21 Mar 2002 07:06:28 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09305 for ; Thu, 21 Mar 2002 07:06:23 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2LC5pM14429; Thu, 21 Mar 2002 13:05:51 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2LC5I523395; Thu, 21 Mar 2002 12:05:19 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 12:05:52 -0000 Message-ID: From: "Mark Watson" To: "'Jonathan Rosenberg'" , Christer Holmberg Cc: sip@ietf.org, gonzalo.camarillo@lmf.ericsson.se Subject: RE: [Sip] PRACK question: draft-ietf-sip-100rel-06 Date: Thu, 21 Mar 2002 12:05:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0D0.BBE52098" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D0D0.BBE52098 Content-Type: text/plain > > > > UA_A sends an INVITE, with SDP (offer 1). > > > > UA_B sends back the first 18x provisional response, WITH > SDP (answer 1). > > > > UA_A sends the first PRACK, WITHOUT SDP. > > > > UA_B sends back the second 18x provisional response, WITHOUT SDP. > > > > UA_A sends the second PRACK, WITH SDP (offer 2). > > This is illegal. According to 100rel: > > If the UAC receives a reliable provisional response with an offer > (this would occur if the UAC sent an INVITE without an offer, in > which case the first reliable provisional response will contain the > offer), it MUST generate an answer in the PRACK. If the > UAC receives > a reliable provisional response with an answer, it MAY generate an > additional offer in the PRACK. If the UAS receives a PRACK with an > offer, it MUST place the answer in the 2xx to the PRACK. > > > Generating additional offers in the PRACK is contingent on > receiving an > answer in the 1xx. The text could be clearer. The statement 'If the UAS receives a PRACK with an offer ...' is not qualified to say that this refers only to the PRACK to a 1xx containing an answer - it could be read as applying to any PRACK, although it's appearence in this particular paragraph ought to give you a hint. This is unless there is another statement somewhere else along the lines of 'The UAC MUST NOT include an offer in a PRACK except when the PRACK acknowledges a 1xx containing an answer.' Perhaps even a table showing all the valid combinations for offers/answers in non-UPDATES would be useful - I think there are only four cases - someone pls correct me if I'm wrong: Each column to be read as an allowable call flow. No additional messages are allowed in the call flow except between the 200 OK of the PRACK and the 200 OK of the INVITE. +-------------------------------+ |Message | 1 | 2 | 3 | 4 | +---------------+---+---+---+---+ |>INVITE | O | O | O | | +---------------+---+---+---+---+ |PRACK | | | O | A | +---------------+---+---+---+---+ |<200 OK (PRACK)| | | A | | +---------------+---+---+---+---+ |<200 OK (INV) | A | | | | +---------------+---+---+---+---+ > The result is that there will only ever be one generating of > an offer in > PRACK, since only the first reliable provisional response can have an > answer. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1D0D0.BBE52098 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] PRACK question: draft-ietf-sip-100rel-06

<snip>
> >
> > UA_A sends an INVITE, with SDP (offer = 1).
> >
> > UA_B sends back the first 18x provisional = response, WITH
> SDP (answer 1).
> >
> > UA_A sends the first PRACK, WITHOUT = SDP.
> >
> > UA_B sends back the second 18x provisional = response, WITHOUT SDP.
> >
> > UA_A sends the second PRACK,  WITH = SDP (offer 2).
>
> This is illegal. According to 100rel:
>
>  If the UAC receives a reliable = provisional response with an offer
>    (this would occur if the UAC = sent an INVITE without an offer, in
>    which case the first reliable = provisional response will contain the
>    offer), it MUST generate an = answer in the PRACK. If the
> UAC receives
>    a reliable provisional = response with an answer, it MAY generate an
>    additional offer in the = PRACK. If the UAS receives a PRACK with an
>    offer, it MUST place the = answer in the 2xx to the PRACK.
>
>
> Generating additional offers in the PRACK is = contingent on
> receiving an
> answer in the 1xx.

The text could be clearer. The statement 'If the UAS = receives a PRACK with an offer ...' is not qualified to say that this = refers only to the PRACK to a 1xx containing an answer - it could be = read as applying to any PRACK, although it's appearence in this = particular paragraph ought to give you a hint.

This is unless there is another statement somewhere = else along the lines of 'The UAC MUST NOT include an offer in a PRACK = except when the PRACK acknowledges a 1xx containing an = answer.'

Perhaps even a table showing all the valid = combinations for offers/answers in non-UPDATES would be useful - I = think there are only four cases - someone pls correct me if I'm = wrong:

Each column to be read as an allowable call flow. No = additional messages are allowed in the call flow except between the 200 = OK of the PRACK and the 200 OK of the INVITE.

+-------------------------------+
|Message        | = 1 | 2 | 3 | 4 |
+---------------+---+---+---+---+
|>INVITE        | O | O = | O |   |
+---------------+---+---+---+---+
|<Rel 1xx       = |   | A | A | O |
+---------------+---+---+---+---+
|>PRACK         = |   |   | O | A |
+---------------+---+---+---+---+
|<200 OK (PRACK)|   |   | A = |   |
+---------------+---+---+---+---+
|<200 OK (INV)  | A |   = |   |   |
+---------------+---+---+---+---+


> The result is that there will only ever be one = generating of
> an offer in
> PRACK, since only the first reliable = provisional response can have an
> answer.
>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1D0D0.BBE52098-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 08:13:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09948 for ; Thu, 21 Mar 2002 08:13:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07943 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 08:13:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06902; Thu, 21 Mar 2002 07:57:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06871 for ; Thu, 21 Mar 2002 07:57:14 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09766 for ; Thu, 21 Mar 2002 07:57:11 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA00391; Thu, 21 Mar 2002 13:56:17 +0100 (MET) Subject: Re: [Sip] Re: Offer by the callee To: Gonzalo Camarillo Cc: Jonathan Rosenberg , sip@ietf.org Date: Thu, 21 Mar 2002 13:56:16 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/21/2002 13:56:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, An example. Alice calls her bank, using an audio stream only; Alice is a good customer. Bob, the Alice's account manager, receives the call, and his terminal is pre-programmed to offer automatically a video stream also and high-quality voice codecs, for good customers. Therefore: - Offer-1 from Alice to Bob: one audio stream with normal voice codec - Offer-2 from Bob to Alice: one audio stream with high-quality codec (not necessarily present in Offer-1, but including supported codecs from Offer-1 to give a fallback possibility), and one video stream As Offer-2 is pre-programmed in Bob's terminal, it is useless for A to start resource reservation for Offer-1. So in the scenario, I was using: - 183 response, to allow Bob to tell Alice "I'm handling your session invitation", so it is not a final response carrying an error message - all port numbers equal to zero, to tell Alice "wait a minute, don't start resource reservation" - and the UPDATE message from Bob to Alice will follow immediatly after 200 Prack with the new offer Offer-2 (this is suggested by the scenarios in the Update draft) Obviously, there is a charging model behind that, but this is another story. Anyhow, Alice has always the possibility to reject the Offer. Best regards Juan Carlos Gonzalo Camarillo on 21/03/2002 05:30:42 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hi, what do you want to put in the offer-2 to be sent that you cannot put in the answer-1? Understanding the scenario you have in mind would be helpful... Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > Thank you for your answer > You are right, but sending a held SDP does not prevent the calling party to > start resource reservation, but only to send media. > I agree with you that normally, a port number to zero indicates refusal of > the media stream. Nevertheless, according to Offer/Answer draft, all port > numbers equal to zero is used also to announce capabilities (section 9), > and very often it is used to say just "don't use this media". > > What I need here is to give to the answerer the possibility to say "Mr.the > Offerer, I'm not rejecting your Invite, but I'd like to send you a new > offer right now, so it is useless to start resource reservation before > receiving this new offer" > > Best regards > Juan Carlos _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 09:31:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11785 for ; Thu, 21 Mar 2002 09:31:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11933 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 09:31:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10682; Thu, 21 Mar 2002 09:13:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10651 for ; Thu, 21 Mar 2002 09:13:50 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11163 for ; Thu, 21 Mar 2002 09:13:45 -0500 (EST) From: frank.derks@philips.com Received: from smtpscan-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id PAA20740 for ; Thu, 21 Mar 2002 15:12:07 +0100 (CET) (envelope-from frank.derks@philips.com) Received: from smtpscan-nl1.philips.com(130.139.36.21) by gw-nl4.philips.com via mwrap (4.0a) id xma020736; Thu, 21 Mar 02 15:12:07 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA02007 for ; Thu, 21 Mar 2002 15:13:45 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA26433 for ; Thu, 21 Mar 2002 15:13:45 +0100 (MET) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 21 Mar 2002 15:12:25 +0100 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 21/03/2002 15:14:37, Serialize complete at 21/03/2002 15:14:37 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004DF299C1256B83_=" Subject: [Sip] Matching requests to server transactions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 004DF299C1256B83_= Content-Type: text/plain; charset="us-ascii" Section 17.2.3 of version 9 of the SIP draft contains the following text: "The request matches a transaction if the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and in the case of a CANCEL request, the method of the request that created the transaction was also CANCEL. This matching rule applies to both INVITE and non-INVITE transactions alike. " It would seem that this text is trying to state the following: - if a CANCEL request is received and its branch and sent-by values match those for a transaction that was created because of the reception of a prior CANCEL request with the same values, then the request matches the transaction. - if a non-CANCEL request is received and its branch and sent-by values match those for a transaction that was created because of the reception of a prior non-CANCEL request (but not necessarily the same type of request!) with the same values, then the request matches the transaction. Is this a correct interpretation? If it is then I suggest re-writing the above text to better reflect this. Regards, Frank --=_alternative 004DF299C1256B83_= Content-Type: text/html; charset="us-ascii"
Section 17.2.3 of version 9 of the SIP draft contains the following text:

"The request matches a transaction if the branch parameter in the request is
equal to the one in the top Via header field of the request that created the
transaction, the sent-by value in the top Via of the request is equal to the
one in the request that created the transaction, and in the case of a CANCEL
request, the method of the request that created the transaction was also
CANCEL. This matching rule applies to both INVITE and non-INVITE transactions
alike. "

It would seem that this text is trying to state the following:

- if a CANCEL request is received and its branch and sent-by values match
  those for a transaction that was created because of the reception of a
  prior CANCEL request with the same values, then the request matches the
  transaction.

- if a non-CANCEL request is received and its branch and sent-by values match
  those for a transaction that was created because of the reception of a
  prior non-CANCEL request (but not necessarily the same type of request!)  
  with the same values, then the request matches the transaction.

Is this a correct interpretation? If it is then I suggest re-writing the
above text to better reflect this.

Regards,

Frank --=_alternative 004DF299C1256B83_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 09:59:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12723 for ; Thu, 21 Mar 2002 09:59:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13647 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 09:59:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12702; Thu, 21 Mar 2002 09:46:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12671 for ; Thu, 21 Mar 2002 09:46:02 -0500 (EST) Received: from blaze.hcltech.com ([203.199.199.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12275 for ; Thu, 21 Mar 2002 09:45:57 -0500 (EST) Received: from netlab.hcltech.com (dinesh.hclt-guindy.co.in [192.168.201.24]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id UAA26186; Thu, 21 Mar 2002 20:36:50 +0530 Message-ID: <3C99F1B9.D5EBBBD0@netlab.hcltech.com> Date: Thu, 21 Mar 2002 20:14:09 +0530 From: Dinesh N Organization: HCL Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, Jonathan Rosenberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Processing CANCEL request at UAS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, In section 9.2 of bis-09, it has been mentioned to refer section 17.2.3 to find/match the transaction to be cancelled. And in section 17.2.3, there is no specific description to match the CANCEL requests to the transaction created by the original request. Hence handling the CANCEL requests will fall into the following place of section 17.2.3. 3527 "For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID Cseq (including the method), and top Via header field match those of the request that created the transaction. " And this matching will only detect the retransmission of CANCEL requests since the method in Cseq is also compared. So how the CANCEL request will be matched to the original request (say INVITE transaction)? Thanks, Dinesh _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 10:04:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12882 for ; Thu, 21 Mar 2002 10:04:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14360 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 10:04:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13209; Thu, 21 Mar 2002 09:52:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13178 for ; Thu, 21 Mar 2002 09:52:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12512 for ; Thu, 21 Mar 2002 09:52:15 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2LEq9l13229; Thu, 21 Mar 2002 08:52:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2LEq9c27694; Thu, 21 Mar 2002 08:52:09 -0600 (CST) Received: from lmf.ericsson.se (rmt160240.am.ericsson.se [138.85.160.240]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA13217; Thu, 21 Mar 2002 08:52:06 -0600 (CST) Message-ID: <3C99F446.36CE7ED7@lmf.ericsson.se> Date: Thu, 21 Mar 2002 16:55:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The situation you are describing does not sound very sensible, because if Alice offers a set of codecs, it is because she wants to use that set of codecs. Therefore, even if Bob sends her an offer with a bunch of extra codecs, the possibilities that Alice sticks to her first offer are very high. Well, if she is using some kind of capability announcement Bob could know that she supports the high quality codec... About the video stream, the QoS reservation will begin when the second offer is sent, so it does not represent any problem. So, even if Alice uses simcap, for instance, and Bob will offer a new codec in an extra offer, it is a good idea to start resource reservation as soon as possible. Just in case Alice refuses the second offer. I understand you scenario, but it does not fit very well with the offer/answer model. In the offer/answer model, I send you an offer, and if you accept it, we have a session. If not, we don't. You are now saying that you do not want to accept the session, but that if the offer was different, you would be willing to accept it... that's why you may have to wait a RTT before you send the second offer. Anyway, if you really want to express that, you can always set your ports to zero, although I do not think it is a very good idea. Regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi Gonzalo, > > An example. > Alice calls her bank, using an audio stream only; Alice is a good customer. > Bob, the Alice's account manager, receives the call, and his terminal is > pre-programmed to offer automatically a video stream also and high-quality > voice codecs, for good customers. > Therefore: > - Offer-1 from Alice to Bob: one audio stream with normal voice codec > - Offer-2 from Bob to Alice: one audio stream with high-quality codec (not > necessarily present in Offer-1, but including supported codecs from Offer-1 > to give a fallback possibility), and one video stream > > As Offer-2 is pre-programmed in Bob's terminal, it is useless for A to > start resource reservation for Offer-1. > So in the scenario, I was using: > - 183 response, to allow Bob to tell Alice "I'm handling your session > invitation", so it is not a final response carrying an error message > - all port numbers equal to zero, to tell Alice "wait a minute, don't start > resource reservation" > - and the UPDATE message from Bob to Alice will follow immediatly after 200 > Prack with the new offer Offer-2 (this is suggested by the scenarios in the > Update draft) > > Obviously, there is a charging model behind that, but this is another > story. Anyhow, Alice has always the possibility to reject the Offer. > > Best regards > Juan Carlos > > Gonzalo Camarillo on 21/03/2002 > 05:30:42 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: Jonathan Rosenberg , sip@ietf.org > Subject: Re: [Sip] Re: Offer by the callee > > Hi, > > what do you want to put in the offer-2 to be sent that you cannot put in > the answer-1? Understanding the scenario you have in mind would be > helpful... > > Gonzalo > > Juan-Carlos.Rojas@alcatel.fr wrote: > > > > Hi Gonzalo, > > > > Thank you for your answer > > You are right, but sending a held SDP does not prevent the calling party > to > > start resource reservation, but only to send media. > > I agree with you that normally, a port number to zero indicates refusal > of > > the media stream. Nevertheless, according to Offer/Answer draft, all port > > numbers equal to zero is used also to announce capabilities (section 9), > > and very often it is used to say just "don't use this media". > > > > What I need here is to give to the answerer the possibility to say > "Mr.the > > Offerer, I'm not rejecting your Invite, but I'd like to send you a new > > offer right now, so it is useless to start resource reservation before > > receiving this new offer" > > > > Best regards > > Juan Carlos -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Thu Mar 21 11:41:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16329 for ; Thu, 21 Mar 2002 11:41:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20512 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 11:41:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18523; Thu, 21 Mar 2002 11:10:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18493 for ; Thu, 21 Mar 2002 11:10:09 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15027 for ; Thu, 21 Mar 2002 11:10:06 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id RAA18530; Thu, 21 Mar 2002 17:09:18 +0100 (MET) Subject: Re: [Sip] Re: Offer by the callee To: Gonzalo Camarillo Cc: Jonathan Rosenberg , sip@ietf.org Date: Thu, 21 Mar 2002 17:09:15 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/21/2002 17:09:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Alice's phone can be pre-prgrammed to use a normal codec, so the terminal will not announce (by default) the high-quality codec (because of any reason, and among others, because it is very likely that when using this high-quality codec, the whole communication will be more expensive). She is sending a normal Invite, not necessarily announcing her capability set. If the terminal announces systematically the entire set of capabilities, it is very likely that the answerer will always pick up the highest quality one, with which the communication will be the most expensive. You see that in this case, Alice is "unable" to control her expenses. Therefore, when Bob sends the bunch of extra codecs, the high-quality one will be surely in the first position, so it is very likely that Alice will use it (except obviously if her terminal does not support such feature). Where I'm a little bit worried with the basic Offer/Answer model (since the counter-offer possibility was never agreed), is that finally, as you say in the mail below, it is very "Offerer-oriented", that is, if the Answerer wants to make a new offer, he is obliged to accept/reject the current offer before. This is not a problem with mid-session offers, since even if the answerer rejects the offer, the session will always come back to the state prior to the offer (which can be assumed to be a known state), so giving the answerer the possibility to generate next a new offer. The main concern is dealing with the first session description agreement, and therefore the first resource reservation procedure, as is the case of my example. Indeed, this possibility has been given to the Offerer, with the new 155 provisional response, which means "Mr. the Offerer, I'm not rejecting the session invitation, but I'm not really happy with the session description, so please provide a new offer in an UPDATE message" Best regards Juan Carlos Gonzalo Camarillo on 21/03/2002 15:55:02 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hi, The situation you are describing does not sound very sensible, because if Alice offers a set of codecs, it is because she wants to use that set of codecs. Therefore, even if Bob sends her an offer with a bunch of extra codecs, the possibilities that Alice sticks to her first offer are very high. Well, if she is using some kind of capability announcement Bob could know that she supports the high quality codec... About the video stream, the QoS reservation will begin when the second offer is sent, so it does not represent any problem. So, even if Alice uses simcap, for instance, and Bob will offer a new codec in an extra offer, it is a good idea to start resource reservation as soon as possible. Just in case Alice refuses the second offer. I understand you scenario, but it does not fit very well with the offer/answer model. In the offer/answer model, I send you an offer, and if you accept it, we have a session. If not, we don't. You are now saying that you do not want to accept the session, but that if the offer was different, you would be willing to accept it... that's why you may have to wait a RTT before you send the second offer. Anyway, if you really want to express that, you can always set your ports to zero, although I do not think it is a very good idea. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 12:12:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18034 for ; Thu, 21 Mar 2002 12:12:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24292 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 12:12:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21264; Thu, 21 Mar 2002 11:53:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21233 for ; Thu, 21 Mar 2002 11:53:32 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17132 for ; Thu, 21 Mar 2002 11:53:28 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2LGr0r16449 for ; Thu, 21 Mar 2002 11:53:00 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Mar 2002 16:52:59 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB004992CD3@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: sip@ietf.org Date: Thu, 21 Mar 2002 16:52:59 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] Codecs selection & QoS reservation--Manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, There a case in my mind: A offers one m= line with 5 codecs also with precondition either local or e2e, B answers with 3 of the 5, and according to manyfolks, both A and B starts to QoS reservation either local or e2e. Since there are 3 codecs can be used for communication, is there a problem that A and B reserve the QoS based on different codecs, let's assume that the codec A used for QoS reservation requires higher QoS that B used, will there be a problem for the session? This is like the one-of-N codecs problem mentioned in unify draft. Shall we mandate that A and B always use the first codec for QoS reservation since the first one is the prefered one? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 12:51:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19734 for ; Thu, 21 Mar 2002 12:51:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28531 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 12:51:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25382; Thu, 21 Mar 2002 12:25:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25354 for ; Thu, 21 Mar 2002 12:25:37 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18535 for ; Thu, 21 Mar 2002 12:25:28 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA03476; Thu, 21 Mar 2002 18:24:54 +0100 (MET) Subject: Re: [Sip] Codecs selection & QoS reservation--Manyfolks To: "Chen, Xin (Xin)" Cc: sip@ietf.org Date: Thu, 21 Mar 2002 18:24:52 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/21/2002 18:24:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Indeed, parties can use any of those negotiated codecs in the list without session re-negotiation. Therefore, should both end-points take into account the highest bandwidth requirements for resource reservation ? Best regards Juan Carlos "Chen, Xin (Xin)" @ietf.org on 21/03/2002 17:52:59 Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] Codecs selection & QoS reservation--Manyfolks Hi, There a case in my mind: A offers one m= line with 5 codecs also with precondition either local or e2e, B answers with 3 of the 5, and according to manyfolks, both A and B starts to QoS reservation either local or e2e. Since there are 3 codecs can be used for communication, is there a problem that A and B reserve the QoS based on different codecs, let's assume that the codec A used for QoS reservation requires higher QoS that B used, will there be a problem for the session? This is like the one-of-N codecs problem mentioned in unify draft. Shall we mandate that A and B always use the first codec for QoS reservation since the first one is the prefered one? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 12:58:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20073 for ; Thu, 21 Mar 2002 12:58:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28934 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 12:58:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26682; Thu, 21 Mar 2002 12:33:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26645 for ; Thu, 21 Mar 2002 12:33:49 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18818 for ; Thu, 21 Mar 2002 12:33:46 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2LHXHr06489 for ; Thu, 21 Mar 2002 12:33:17 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Mar 2002 17:33:16 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB004992CE8@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: Juan-Carlos.Rojas@alcatel.fr, "Chen, Xin (Xin)" Cc: sip@ietf.org Subject: RE: [Sip] Codecs selection & QoS reservation--Manyfolks Date: Thu, 21 Mar 2002 17:33:15 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Juan, Unless we have a globle QoS mapping standards or both ends use same QoS reservation protocol, I double both ends will get the same answer which needs more QoS. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] Sent: 21 March 2002 17:25 To: Chen, Xin (Xin) Cc: sip@ietf.org Subject: Re: [Sip] Codecs selection & QoS reservation--Manyfolks Hi, Indeed, parties can use any of those negotiated codecs in the list without session re-negotiation. Therefore, should both end-points take into account the highest bandwidth requirements for resource reservation ? Best regards Juan Carlos "Chen, Xin (Xin)" @ietf.org on 21/03/2002 17:52:59 Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: [Sip] Codecs selection & QoS reservation--Manyfolks Hi, There a case in my mind: A offers one m= line with 5 codecs also with precondition either local or e2e, B answers with 3 of the 5, and according to manyfolks, both A and B starts to QoS reservation either local or e2e. Since there are 3 codecs can be used for communication, is there a problem that A and B reserve the QoS based on different codecs, let's assume that the codec A used for QoS reservation requires higher QoS that B used, will there be a problem for the session? This is like the one-of-N codecs problem mentioned in unify draft. Shall we mandate that A and B always use the first codec for QoS reservation since the first one is the prefered one? Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 14:16:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21963 for ; Thu, 21 Mar 2002 14:16:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04605 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 14:16:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01916; Thu, 21 Mar 2002 13:39:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01889 for ; Thu, 21 Mar 2002 13:39:22 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21074 for ; Thu, 21 Mar 2002 13:39:18 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2LIdHkY004468 for ; Thu, 21 Mar 2002 19:39:17 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 21 19:39:17 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 19:39:17 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA030220EFCF@efijont102> From: "Christer Holmberg (LMF)" To: "'sip@ietf.org'" Date: Thu, 21 Mar 2002 19:39:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] non-SIP-URI and tag Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, As we have discussed before, if a SIP-URI contains URI parameters the URI must be put between brackets. Otherwise the parameters will be regarded as header parameter (eg the tag parameter). Now, since we are allowed to use other kinds of URIs in the To- and From headers (my client may not know the specific semantics of those), and the ABNF allows those URIs to contain the ";" characters (which are used to separate parameters in the SIP-URI), does this mean that ALL URIs must be put within brackets if they contain the ";" character - even if it doesn't have anything to do with URI parameters (I assume that is possible)? Otherwise, when my parser finds a ";" character when parsing the non-SIP-URI, how does it now if the character is simply a character within some part of the URI, or if it separates URI parameters, or if it separates the URI from the rest of the header? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 14:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22367 for ; Thu, 21 Mar 2002 14:24:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05092 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 14:24:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04089; Thu, 21 Mar 2002 14:06:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04060 for ; Thu, 21 Mar 2002 14:06:17 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21700 for ; Thu, 21 Mar 2002 14:06:11 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2LJ6BkY008031 for ; Thu, 21 Mar 2002 20:06:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 21 20:05:47 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 20:05:47 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA030220EFD2@efijont102> From: "Christer Holmberg (LMF)" To: "'sip@ietf.org'" Date: Thu, 21 Mar 2002 20:05:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] Reason header question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, To my understanding the following case is in the requirements for the Reason header, but my question is which code to use. Assume that I send an INVITE, which gets forked. I may receive 18x responses from different servers, and I MAY start doing coced and/or resource negoatiation with some of them. For some reason (may be because of the negoatiation above, or something else) I decide to send a tagged BYE to one or many servers, to terminate the call setup. Now, one could argue that I should use code value 1 (Call Completed Elsewhere), but I don't really think that's always a good choise. I do NOT terminate the call because someone else established a session, but because of other issue. For example, I may have chosen to use a specific codec with every server, and one or more of the servers may not support that specific codec, so I terminate the setup... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 14:27:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22528 for ; Thu, 21 Mar 2002 14:27:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05307 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 14:27:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04268; Thu, 21 Mar 2002 14:09:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04207 for ; Thu, 21 Mar 2002 14:08:58 -0500 (EST) Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21749; Thu, 21 Mar 2002 14:08:51 -0500 (EST) Received: from TXDWILLIS2 (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.11.6/8.11.6) with ESMTP id g2LJ7ag11007; Thu, 21 Mar 2002 13:07:37 -0600 From: "Dean Willis" To: , Cc: , "'Rohan Mahy'" , , Date: Thu, 21 Mar 2002 13:07:24 -0600 Message-ID: <000001c1d10b$a4c25850$84bf3fa6@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] www.softarmor.com down due to power outage, alternate available Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My hosting facility seems to have an unplanned power outage due to construction, so the main SIP and SIPPING supplemental websites are offline. The good news is that the backup sites at http://kevlar.softarmoir.com/sipwg and http://kevlar.softarmor.com/sipping appear to be on line. You can use these sites for retrieving information until the main site comes back on line. My mail queue is also affected, so I may not be responsive to email this afternoon. If needed, I can be reached at mobile +1 214 244 3703. I shouldn't lose any mail, but messages delivered to the main system and not polled by me prior to the outage are temporarily unavailable. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 14:36:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22935 for ; Thu, 21 Mar 2002 14:36:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06093 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 14:36:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04795; Thu, 21 Mar 2002 14:18:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04768 for ; Thu, 21 Mar 2002 14:18:49 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22078 for ; Thu, 21 Mar 2002 14:18:46 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2LJIlD20229; Thu, 21 Mar 2002 14:18:47 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA11541; Thu, 21 Mar 2002 13:18:46 -0600 (CST) Message-ID: <3C9A31F5.4796A200@lucent.com> Date: Thu, 21 Mar 2002 13:18:13 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rsparks@dynamicsoft.com CC: SIP LIST Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] draft-ietf-sip-refer-02.txt clarification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert: Going through draft-ietf-sip-refer-02.txt, I note that sending a NOTIFY to REFER is a SHOULD strength. Any reason why not a MUST, since notification appears to be an integral part of the dialog (and the service) since it passes information on the result of the subsequent INVITE. Also, in section 3.5.3.2 you say that "Each NOTIFY MUST contain a body of type "message/sipfrag" (see IANA)." I interpret "see IANA" to mean see Section 5 (IANA Considerations) for more information about message/sipfrag MIME type. But there isn't any information on it in Section 5. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 16:11:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25668 for ; Thu, 21 Mar 2002 16:11:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA12577 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 16:11:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10536; Thu, 21 Mar 2002 15:37:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10508 for ; Thu, 21 Mar 2002 15:37:57 -0500 (EST) Received: from crash.dfw.dynamicsoft.com ([63.110.3.64]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24579 for ; Thu, 21 Mar 2002 15:37:53 -0500 (EST) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g2LKeoA01056; Thu, 21 Mar 2002 14:40:58 -0600 From: Robert Sparks To: Vijay Gurbani Cc: SIP LIST In-Reply-To: <3C9A31F5.4796A200@lucent.com> References: <3C9A31F5.4796A200@lucent.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Mar 2002 14:37:02 -0600 Message-Id: <1016743030.1253.6.camel@wireless-dhcp-187-186> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-ietf-sip-refer-02.txt clarification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Thu, 2002-03-21 at 13:18, Vijay Gurbani wrote: > Robert: > > Going through draft-ietf-sip-refer-02.txt, I note that sending a NOTIFY to > REFER is a SHOULD strength. Any reason why not a MUST, since notification > appears to be an integral part of the dialog (and the service) since it > passes information on the result of the subsequent INVITE. This was heavily debated when we shifted to the implicit subscription model. The consensus landed on SHOULD strength because there were people who were not interested in the ability to transmit the result and were not willing to pay the overhead of the NOTIFY transaction. > > Also, in section 3.5.3.2 you say that "Each NOTIFY MUST contain a body of type > "message/sipfrag" (see IANA)." I interpret "see IANA" to mean see Section 5 > (IANA Considerations) for more information about message/sipfrag > MIME type. But there isn't any information on it in Section 5. No, it really meant see IANA. That's where you would go to get information on registered mime types. -02 was written under the expectation that the registration described in sip-mimetypes would have already taken place. Since message/sip was defined in bis, message/sipfrag will probably be pulled back into the next iteration of REFER. RjS > > Thanks, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 17:46:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28265 for ; Thu, 21 Mar 2002 17:46:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19451 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 17:46:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17840; Thu, 21 Mar 2002 17:27:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24245 for ; Thu, 21 Mar 2002 12:12:41 -0500 (EST) Received: from hotmail.com (f264.law7.hotmail.com [216.33.236.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18027 for ; Thu, 21 Mar 2002 12:12:37 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Mar 2002 09:12:05 -0800 Received: from 166.63.190.112 by lw7fd.law7.hotmail.msn.com with HTTP; Thu, 21 Mar 2002 17:12:05 GMT X-Originating-IP: [166.63.190.112] From: "Sriramp Parameswar" To: zmolek@avaya.com, sip@ietf.org Subject: RE: [Sip] REFER Security Date: Thu, 21 Mar 2002 17:12:05 +0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Mar 2002 17:12:05.0295 (UTC) FILETIME=[8660E3F0:01C1D0FB] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org

No - remember C can contact A only if the Referred-By header is valid - thus if A wants to remain anonymous he can send a "bogus" Referred-By Header.

The other thing I like with this mechanism is that Party C (transfer target) needs to contact Party A (transferor) *only* if he thinks that he needs to validate the source of the REFER - other wise the REFER goes on its merry way. Also if he contacts Party A and receives a  reply with 'huh? - not me' then Party C can reject the call.

Thanks,

Sriram

>From: "Zmolek, Andrew (Andrew)"
>To: "Sriramp Parameswar" ,
>Subject: RE: [Sip] REFER Security
>Date: Wed, 20 Mar 2002 16:23:03 -0700
>
>Are you suggesting that security trumps privacy in this case?
>
>--Andy
>
>-----Original Message-----
>From: Sriramp Parameswar [mailto:sriramkp@hotmail.com]
>Sent: Wednesday, March 20, 2002 2:08 PM
>To: sip@ietf.org
>Subject: [Sip] REFER Security
>
>
>Hi:
>
>I tend to fall into the camp that believes when you have any intermediary you weaken security - also I am queasy about self signed certificates.
>
>I would put my vote clearly behind C (transfer target from cc-transfer) directly contacts A (transferor in cc-transfer) and asking for verification. This was shown as VERIFY in Roberts slides - and may I suggest that we use NEGOTIATE as the method that does this verification check.
>
>Thanks,
>
>Sriram
>
> _____
>
>Join the world's largest e-mail service with MSN Hotmail. Click Here
>_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
>

MSN Photos is the easiest way to share and print your photos: Click Here
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 18:02:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28981 for ; Thu, 21 Mar 2002 18:02:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20884 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 18:02:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19429; Thu, 21 Mar 2002 17:45:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19383 for ; Thu, 21 Mar 2002 17:45:41 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28235 for ; Thu, 21 Mar 2002 17:45:35 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2LMiti25583; Thu, 21 Mar 2002 16:44:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2LMisX20022; Thu, 21 Mar 2002 16:44:55 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA28923; Thu, 21 Mar 2002 16:44:52 -0600 (CST) Message-ID: <3C9A6315.BC796661@lmf.ericsson.se> Date: Fri, 22 Mar 2002 00:47:49 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, As you point out, a possible counter offer has been ruled out from the spec, together with all the advantages and disadvantages that this implies. About the 155, it is not intended to break the offer/answer model. Regards, Gonzalo Juan-Carlos.Rojas@alcatel.fr wrote: > > Hi, > > Alice's phone can be pre-prgrammed to use a normal codec, so the terminal > will not announce (by default) the high-quality codec (because of any > reason, and among others, because it is very likely that when using this > high-quality codec, the whole communication will be more expensive). She is > sending a normal Invite, not necessarily announcing her capability set. > If the terminal announces systematically the entire set of capabilities, it > is very likely that the answerer will always pick up the highest quality > one, with which the communication will be the most expensive. You see that > in this case, Alice is "unable" to control her expenses. > Therefore, when Bob sends the bunch of extra codecs, the high-quality one > will be surely in the first position, so it is very likely that Alice will > use it (except obviously if her terminal does not support such feature). > > Where I'm a little bit worried with the basic Offer/Answer model (since the > counter-offer possibility was never agreed), is that finally, as you say in > the mail below, it is very "Offerer-oriented", that is, if the Answerer > wants to make a new offer, he is obliged to accept/reject the current offer > before. > This is not a problem with mid-session offers, since even if the answerer > rejects the offer, the session will always come back to the state prior to > the offer (which can be assumed to be a known state), so giving the > answerer the possibility to generate next a new offer. > > The main concern is dealing with the first session description agreement, > and therefore the first resource reservation procedure, as is the case of > my example. > Indeed, this possibility has been given to the Offerer, with the new 155 > provisional response, which means "Mr. the Offerer, I'm not rejecting the > session invitation, but I'm not really happy with the session description, > so please provide a new offer in an UPDATE message" > > Best regards > Juan Carlos > > Gonzalo Camarillo on 21/03/2002 > 15:55:02 > > To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL > cc: Jonathan Rosenberg , sip@ietf.org > Subject: Re: [Sip] Re: Offer by the callee > > Hi, > > The situation you are describing does not sound very sensible, because > if Alice offers a set of codecs, it is because she wants to use that set > of codecs. Therefore, even if Bob sends her an offer with a bunch of > extra codecs, the possibilities that Alice sticks to her first offer are > very high. Well, if she is using some kind of capability announcement > Bob could know that she supports the high quality codec... > > About the video stream, the QoS reservation will begin when the second > offer is sent, so it does not represent any problem. > > So, even if Alice uses simcap, for instance, and Bob will offer a new > codec in an extra offer, it is a good idea to start resource reservation > as soon as possible. Just in case Alice refuses the second offer. > > I understand you scenario, but it does not fit very well with the > offer/answer model. In the offer/answer model, I send you an offer, and > if you accept it, we have a session. If not, we don't. You are now > saying that you do not want to accept the session, but that if the offer > was different, you would be willing to accept it... that's why you may > have to wait a RTT before you send the second offer. > > Anyway, if you really want to express that, you can always set your > ports to zero, although I do not think it is a very good idea. > > Regards, > > Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Thu Mar 21 18:08:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29149 for ; Thu, 21 Mar 2002 18:08:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21112 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 18:08:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19761; Thu, 21 Mar 2002 17:51:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19730 for ; Thu, 21 Mar 2002 17:51:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28457 for ; Thu, 21 Mar 2002 17:51:14 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2LMpHl20731 for ; Thu, 21 Mar 2002 16:51:17 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2LMpHV17274 for ; Thu, 21 Mar 2002 16:51:17 -0600 (CST) Received: from lmf.ericsson.se (rmt160152.am.ericsson.se [138.85.160.152]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29591; Thu, 21 Mar 2002 16:51:13 -0600 (CST) Message-ID: <3C9A6493.2A3DB7EE@lmf.ericsson.se> Date: Fri, 22 Mar 2002 00:54:11 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Christer Holmberg (LMF)" CC: "'sip@ietf.org'" Subject: Re: [Sip] Reason header question References: <0154633DAF7BD4119C360002A513AA030220EFD2@efijont102> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Christer, I am a little behind with my email. I have to answer a couple of other previous emails related to the reason draft as well. My idea is to have a little dicussion on the requirements. Depending on that discussion, we will decide to get rid of the codes you are referring to, or, on the other hand, decide which ones are essential and which are not. Regards, Gonzalo "Christer Holmberg (LMF)" wrote: > > Hi, > > To my understanding the following case is in the requirements for the Reason header, but my question is which code to use. > > Assume that I send an INVITE, which gets forked. I may receive 18x responses from different servers, and I MAY start doing coced and/or resource negoatiation with some of them. > > For some reason (may be because of the negoatiation above, or something else) I decide to send a tagged BYE to one or many servers, to terminate the call setup. > > Now, one could argue that I should use code value 1 (Call Completed Elsewhere), but I don't really think that's always a good choise. I do NOT terminate the call because someone else established a session, but because of other issue. For example, I may have chosen to use a specific codec with every server, and one or more of the servers may not support that specific codec, so I terminate the setup... > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Thu Mar 21 18:21:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29591 for ; Thu, 21 Mar 2002 18:21:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA21979 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 18:21:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20866; Thu, 21 Mar 2002 18:02:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20805 for ; Thu, 21 Mar 2002 18:02:23 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28972; Thu, 21 Mar 2002 18:02:17 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA00049; Thu, 21 Mar 2002 18:02:20 -0500 (EST) Received: from cs.columbia.edu (cta.ietf53.cw.net [166.63.183.191]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2LN2JPm021242 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 21 Mar 2002 18:02:19 -0500 (EST) Message-ID: <3C9A6662.71CAB25B@cs.columbia.edu> Date: Thu, 21 Mar 2002 17:01:54 -0600 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sipping@ietf.org, sip-implementors@cs.columbia.edu, simple@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 10th SIPit SIP interoperability event Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.sipforum.org/sections.php?op=viewarticle&artid=86 for details. Reminder: Please register and book rooms by 3/25. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 21 19:56:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01540 for ; Thu, 21 Mar 2002 19:56:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27082 for sip-archive@odin.ietf.org; Thu, 21 Mar 2002 19:56:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25620; Thu, 21 Mar 2002 19:26:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25590 for ; Thu, 21 Mar 2002 19:26:49 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01066 for ; Thu, 21 Mar 2002 19:26:43 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2M0Qgoq027149 for ; Fri, 22 Mar 2002 01:26:42 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Mar 22 01:24:52 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 01:16:39 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA030220EFD9@efijont102> From: "Christer Holmberg (LMF)" To: "'Juan-Carlos.Rojas@alcatel.fr '" , "Gonzalo Camarillo Gonzalez (LMF)" Cc: "'Jonathan Rosenberg '" , "'sip@ietf.org '" Subject: RE: [Sip] Re: Offer by the callee Date: Fri, 22 Mar 2002 01:26:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Are you talking about some kind of callback functionality? In that case I guess you would have to send some non-2xx response to the received INVITE, and then send a new INVITE with your offer. But, I guess that's something you don't want to do. I guess one possibility could be to return a 200, with the mode set to "inactive", and then (when you have received the ACK) send a re-INVITE, with a new set of codecs. Maybe not the most comfortable way of doing it, but... I think the reason the rule, saying that the codec set in the answer must be a subset to the set in the offer, was to solve a number of problems, so I don't think we want to change that again... Regards, Christer Holmberg Ericsson Finland -----Original Message----- From: Juan-Carlos.Rojas@alcatel.fr To: Gonzalo Camarillo Cc: Jonathan Rosenberg; sip@ietf.org Sent: 3/21/2002 5:09 PM Subject: Re: [Sip] Re: Offer by the callee Hi, Alice's phone can be pre-prgrammed to use a normal codec, so the terminal will not announce (by default) the high-quality codec (because of any reason, and among others, because it is very likely that when using this high-quality codec, the whole communication will be more expensive). She is sending a normal Invite, not necessarily announcing her capability set. If the terminal announces systematically the entire set of capabilities, it is very likely that the answerer will always pick up the highest quality one, with which the communication will be the most expensive. You see that in this case, Alice is "unable" to control her expenses. Therefore, when Bob sends the bunch of extra codecs, the high-quality one will be surely in the first position, so it is very likely that Alice will use it (except obviously if her terminal does not support such feature). Where I'm a little bit worried with the basic Offer/Answer model (since the counter-offer possibility was never agreed), is that finally, as you say in the mail below, it is very "Offerer-oriented", that is, if the Answerer wants to make a new offer, he is obliged to accept/reject the current offer before. This is not a problem with mid-session offers, since even if the answerer rejects the offer, the session will always come back to the state prior to the offer (which can be assumed to be a known state), so giving the answerer the possibility to generate next a new offer. The main concern is dealing with the first session description agreement, and therefore the first resource reservation procedure, as is the case of my example. Indeed, this possibility has been given to the Offerer, with the new 155 provisional response, which means "Mr. the Offerer, I'm not rejecting the session invitation, but I'm not really happy with the session description, so please provide a new offer in an UPDATE message" Best regards Juan Carlos Gonzalo Camarillo on 21/03/2002 15:55:02 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hi, The situation you are describing does not sound very sensible, because if Alice offers a set of codecs, it is because she wants to use that set of codecs. Therefore, even if Bob sends her an offer with a bunch of extra codecs, the possibilities that Alice sticks to her first offer are very high. Well, if she is using some kind of capability announcement Bob could know that she supports the high quality codec... About the video stream, the QoS reservation will begin when the second offer is sent, so it does not represent any problem. So, even if Alice uses simcap, for instance, and Bob will offer a new codec in an extra offer, it is a good idea to start resource reservation as soon as possible. Just in case Alice refuses the second offer. I understand you scenario, but it does not fit very well with the offer/answer model. In the offer/answer model, I send you an offer, and if you accept it, we have a session. If not, we don't. You are now saying that you do not want to accept the session, but that if the offer was different, you would be willing to accept it... that's why you may have to wait a RTT before you send the second offer. Anyway, if you really want to express that, you can always set your ports to zero, although I do not think it is a very good idea. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 09:40:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22749 for ; Fri, 22 Mar 2002 09:40:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07869 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 09:40:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05266; Fri, 22 Mar 2002 09:13:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05202 for ; Fri, 22 Mar 2002 09:13:03 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21831; Fri, 22 Mar 2002 09:12:52 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA14741; Fri, 22 Mar 2002 09:19:46 +0100 (MET) Subject: Re: [Sip] www.softarmor.com down due to power outage, alternate available To: "Dean Willis" Cc: , , , "'Rohan Mahy'" , , Date: Fri, 22 Mar 2002 09:19:44 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 09:19:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Dean, Thank you for this information. A small typo in the sipwg url ("softarmor" instead of "softarmoir"): http://kevlar.softarmor.com/sipwg Best regards Juan Carlos "Dean Willis" @ietf.org on 21/03/2002 20:07:24 Sent by: sip-admin@ietf.org To: , cc: , "'Rohan Mahy'" , , Subject: [Sip] www.softarmor.com down due to power outage, alternate available My hosting facility seems to have an unplanned power outage due to construction, so the main SIP and SIPPING supplemental websites are offline. The good news is that the backup sites at http://kevlar.softarmoir.com/sipwg and http://kevlar.softarmor.com/sipping appear to be on line. You can use these sites for retrieving information until the main site comes back on line. My mail queue is also affected, so I may not be responsive to email this afternoon. If needed, I can be reached at mobile +1 214 244 3703. I shouldn't lose any mail, but messages delivered to the main system and not polled by me prior to the outage are temporarily unavailable. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 13:45:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28488 for ; Fri, 22 Mar 2002 13:45:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09771 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 13:45:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08273; Fri, 22 Mar 2002 13:22:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08213 for ; Fri, 22 Mar 2002 13:22:51 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28013 for ; Fri, 22 Mar 2002 13:22:49 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA01285; Fri, 22 Mar 2002 10:28:51 +0100 (MET) Subject: RE: [Sip] Re: Offer by the callee To: "Christer Holmberg (LMF)" Cc: "Gonzalo Camarillo Gonzalez (LMF)" , "'Jonathan Rosenberg '" , "'sip@ietf.org '" Date: Fri, 22 Mar 2002 10:25:41 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 10:28:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Christer, Thank you for your answer. A small clarification. Please see the first mails on this thread, where I included a call flow (I'm not including the entire set of exchanged mails, because somebody in the list was very angry with that, and he is right). First of all, the counter-offer possibility was not agreed, I'm not asking to re-open the debate, I hope this is very clear now. In the call flow I presented originally, I was using *strictly* the offer-answer model. I don't think that I was using something forbidden in the corresponding drafts (offer/answer, update, manyfolks); indeed, my main purpose is to build scenarios using all these drafts. My concern was only that, as the callee was receiving an offer, he doesn't want to take it as is (even if he is obliged to provide an answer to this offer), but he doesn't want to reject the session invitation either: he knows that he will make a "better" offer. The question, which is maybe more related to manyfolks was to give the callee the possibility the indicate to the calling to not start a useless resource reservation because he wants to send a new offer. Best regards Juan Carlos "Christer Holmberg (LMF)" on 22/03/2002 01:26:39 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, "Gonzalo Camarillo Gonzalez (LMF)" cc: "'Jonathan Rosenberg '" , "'sip@ietf.org '" Subject: RE: [Sip] Re: Offer by the callee Hi, Are you talking about some kind of callback functionality? In that case I guess you would have to send some non-2xx response to the received INVITE, and then send a new INVITE with your offer. But, I guess that's something you don't want to do. I guess one possibility could be to return a 200, with the mode set to "inactive", and then (when you have received the ACK) send a re-INVITE, with a new set of codecs. Maybe not the most comfortable way of doing it, but... I think the reason the rule, saying that the codec set in the answer must be a subset to the set in the offer, was to solve a number of problems, so I don't think we want to change that again... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 13:47:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28524 for ; Fri, 22 Mar 2002 13:47:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09952 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 13:47:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08245; Fri, 22 Mar 2002 13:22:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08205 for ; Fri, 22 Mar 2002 13:22:50 -0500 (EST) Received: from aifhs8.alcatel.fr (una200.alcatel.fr [212.208.74.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28011 for ; Fri, 22 Mar 2002 13:22:48 -0500 (EST) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA08636; Fri, 22 Mar 2002 10:55:03 +0100 (MET) Subject: Re: [Sip] Re: Offer by the callee To: Gonzalo Camarillo Cc: "'Jonathan Rosenberg '" , "Christer Holmberg (LMF)" , sip@ietf.org Date: Fri, 22 Mar 2002 10:55:00 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/22/2002 10:55:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Gonzalo, Thank you for this interesting debate, so I think we can close the thread. My conclusion is that the "all port numbers to zero in 183 response" is maybe not a beautiful solution, but it is a *legal* one (it is not against any draft); anyhow, there is no other possibility for the call flow presented in this thread. Do note that I'm not asking to re-open the debate on the counter-offer story (even if personally I don't love a lot the final result); indeed I used strictly the offer-answer model in the call flow. I have only a last question: generally speaking, a party cannot send a new offer, while there is still a "pending offer", that is: - the party received an offer, and he has not sent an answer yet - the party sent an offer, and he has not received an answer yet The resource reservation process associated to a given offer starts when the offer is accepted, that is, when the answer to the offer has been sent/received. Therefore, a new offer can be generated by any of the parties, even if the resource reservation process for a previously answered offer has not finished yet. In other words, a new offer can be sent as soon as the previous offer has been answered (following the rules of the Offer/answer draft), but it is not required that the current-status reach the desired-status. Do you agree on that ? Best regards Juan Carlos Gonzalo Camarillo on 21/03/2002 23:47:49 To: Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee Hi, As you point out, a possible counter offer has been ruled out from the spec, together with all the advantages and disadvantages that this implies. About the 155, it is not intended to break the offer/answer model. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 14:38:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29785 for ; Fri, 22 Mar 2002 14:38:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13999 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 14:38:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12437; Fri, 22 Mar 2002 14:18:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12408 for ; Fri, 22 Mar 2002 14:18:27 -0500 (EST) Received: from daimanta.ascend.com (h152-148-40-20.outland.lucent.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29175 for ; Fri, 22 Mar 2002 14:18:24 -0500 (EST) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id OAA27910 for ; Fri, 22 Mar 2002 14:17:56 -0500 (EST) Received: from lucent.com ([135.140.180.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id NAA22499 for ; Fri, 22 Mar 2002 13:46:33 -0500 (EST) Message-ID: <3C9B8360.5040804@lucent.com> Date: Fri, 22 Mar 2002 14:17:52 -0500 From: Kim Liu Organization: Lucent Technologies User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Quick requestion about REFER+Replaces: examples Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In draft-ietf-sip-refer-02.txt and draft-bhatia-3pcc-refer-01.txt there are several examples presented with the Replaces header in a URL as: Refer-To: sip:dave@denver.com?Replaces:12345%40192.168.118.3;to-tag=12345;from-tag=5FFE-3994; Just to double check my understanding of the URL header parsing, shouldn't all of those be more or less: Refer-To: sip:dave@denver.com?Replaces=12345%40192.168.118.3%3bto%2dtag%3d12345%3bfrom%2dtag%3d5FFE%2d3994; Just trying to make sure I haven't missed exactly where the to-tag and from-tag belongs in this case. -- Kim Liu kliu@lucent.com : Everyone is a darn fool for at Senior Software Engineer : least five minutes a day; Lucent Technologies : wisdom consists of not Clearwater, FL, 33761 : exceeding the limit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 15:54:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01505 for ; Fri, 22 Mar 2002 15:54:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18291 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 15:54:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17121; Fri, 22 Mar 2002 15:30:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17094 for ; Fri, 22 Mar 2002 15:30:48 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01084 for ; Fri, 22 Mar 2002 15:30:45 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GTE00G0169WYE@firewall.wcom.com> for sip@ietf.org; Fri, 22 Mar 2002 20:29:56 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GTE00FC169VTK@firewall.wcom.com>; Fri, 22 Mar 2002 20:29:55 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GTE00K0169UOT@pmismtp01.wcomnet.com>; Fri, 22 Mar 2002 20:29:55 +0000 (GMT) Received: from ajohnston ([166.38.62.100]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GTE00J5F69DZR@pmismtp01.wcomnet.com>; Fri, 22 Mar 2002 20:29:39 +0000 (GMT) Date: Fri, 22 Mar 2002 14:29:04 -0600 From: Alan Johnston Subject: RE: [Sip] Quick requestion about REFER+Replaces: examples In-reply-to: <3C9B8360.5040804@lucent.com> To: "'Kim Liu'" , sip@ietf.org Message-id: <000201c1d1e0$368b8fc0$c18c4041@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Kim, You are right. The lack of escaping makes the examples in these drafts more readable but perhaps less accurate per the syntax. Take a look at the SIP Service Examples draft (http://search.ietf.org/internet-drafts/draft-ietf-sipping-service-examp les-00.txt) that show the escaping of the Replaces header in Refer-To headers. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Kim Liu > Sent: Friday, March 22, 2002 1:18 PM > To: sip@ietf.org > Subject: [Sip] Quick requestion about REFER+Replaces: examples > > > In draft-ietf-sip-refer-02.txt and > draft-bhatia-3pcc-refer-01.txt there > are several examples presented with the Replaces header in a URL as: > > Refer-To: > sip:dave@denver.com?Replaces:12345%40192.168.118.3;to-tag=1234 > 5;from-tag=5FFE-3994; > > Just to double check my understanding of the URL header parsing, > shouldn't all of those be more or less: > > Refer-To: > sip:dave@denver.com?Replaces=12345%40192.168.118.3%3bto%2dtag% > 3d12345%3bfrom%2dtag%3d5FFE%2d3994; > > Just trying to make sure I haven't missed exactly where the > to-tag and > from-tag belongs in this case. > > -- > Kim Liu kliu@lucent.com : Everyone is a darn fool for at > Senior Software Engineer : least five minutes a day; > Lucent Technologies : wisdom consists of not > Clearwater, FL, 33761 : exceeding the limit > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 20:38:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05490 for ; Fri, 22 Mar 2002 20:38:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07896 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 20:38:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06346; Fri, 22 Mar 2002 20:16:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06312 for ; Fri, 22 Mar 2002 20:16:38 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05247 for ; Fri, 22 Mar 2002 20:16:36 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2N1G6Y26063; Fri, 22 Mar 2002 17:16:07 -0800 (PST) Received: from oranlt ([161.44.238.52]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACK35997; Fri, 22 Mar 2002 17:15:39 -0800 (PST) From: "David R. Oran" To: "'Gonzalo Camarillo'" , "'Alan O'Neill'" Cc: Subject: RE: [Sip] Re: Manyfolks Clarifications Date: Fri, 22 Mar 2002 20:15:14 -0500 Organization: Cisco Systems Message-ID: <000301c1d208$57abc210$34ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3C996804.906E2883@lmf.ericsson.se> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I believe the situation is much simpler than you are making out, and has nothing really to do with resource reservation, or QoS itself. Rather, it has to do with whether you can do a 1/2 round trip optimization in the call establishment state machine. To squeeze this out you need to distinguish two cases: 1) The other party has end-to-end admission control signaling, and hence I can use local state transitions of the QoS admission control machine I run with him to set the pre-condition satisfied state based on feedback in the QoS signaling from the other party. 2) The other party has only "local" admission control signaling, and hence I need to wait from them to explicitly tell me a precondition was satisfied before entering an alerting state, rather than inferring it as can be sometimes done in the end-to-end case. This is not some cosmic indicator about the nature of QoS; only an optimization knowing the nature of the other party's QoS signaling can provide. Dave > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Wednesday, March 20, 2002 11:57 PM > To: Alan O'Neill > Cc: sip@ietf.org > Subject: [Sip] Re: Manyfolks Clarifications > > > Hello, > > Alan O'Neill wrote: > > > The above discussion therefore suggests to me that all > preconditions > > must be assumed to be end to end, that the e2e tag for the QoS > > mechanism is useless because it can never be safely applied, and > > therefore that the e2e tag be removed. > > Look at the DCS architecture. They can be sure when they have > e2e QoS resources. And in my intranet, when my QoS > reservation protocol tells me that I have e2e QoS service, it > is because I have it. > > If you think that having e2e QoS is impossible, you should > provide feedback to a different WG. Not SIP. > > > > > The local/remote model is on the right path but I believe > incomplete. > > Essentially, the model should be that the MN has an SLA wrt > QoS with > > some limited scope (on-net, offnet to specific prefixes etc). The > > caller seeking preconditions simply adds in the Invite that that is > > the case, and will clearly only do so if believes it has a > candidate > > SLA at its end. > > Look at the 3GPP architecture. They have enough resources in > the backbone. The only thing that worries them is the radio > interface. With the local and remote tags they perform PDP > context activation... it works. > > > >but the UAs should still be able to reduce > > their preconditions to attempt a best effort call in these > >circumstances if they so desire. > > This is always possible. > > > > A related issue that I would like to raise is that given that the > > actual IP prefix of the callee is not known at the time of > the offer > > (and hence the caller neither actually knows if it does > have an SLA or > > a QoS mech for that callee prefix), it is critical that the > > preconditons be able to be flexibly adjusted in response to > additional > > information. > > > That's why you have the carry the current status in the SDP. > Because once you receive the first answer you can update it > (because you know the destination IP address)... and if you > required e2e QoS and after getting the remote IP address you > notice that it is impossible, you do not want to establish > the session, because your requirement cannot be fulfilled. If > you want, you can send a new offer without preconditions, but > the first offer/asnwer fails correctly, because your > preconditions could not be met. > > > I would therefore suggest > > that preconditions should be able to be increased or decreased at > > either end, and not just increased. > > You can always send new offers. The only place where you can > only upgrade the strength tag is within a single offer/answer > exchange. > > Thanks for your comments, > > Gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 22 22:40:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08296 for ; Fri, 22 Mar 2002 22:40:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA16448 for sip-archive@odin.ietf.org; Fri, 22 Mar 2002 22:40:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15157; Fri, 22 Mar 2002 22:23:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15126 for ; Fri, 22 Mar 2002 22:23:46 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07279 for ; Fri, 22 Mar 2002 22:23:43 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 22:23:15 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46A962C4@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: sip@ietf.org Date: Fri, 22 Mar 2002 22:23:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Page 7 top ' Note that the use of the segmented status-type does not prevent bottlenecks in the backbone, only in the access networks.' The wording here is inappropriate as it seems to suggest that e2e is somehow different and more to the point better, than local /remote but this is clearly not universally true. For local/remote tags I can run independent bidirectional RSVP/DOCSIS/PDP context QoS sessions over two accesses to the UAs local cores, and then have preprovisioned backbone sufficient for call load betwen those cores. For e2e tags I can run RSVP end to end through access-core-access and again will use a pre-provisioned core for the call load. In both cases, both UAs will get feedback from the admission control attempt into the core bandwidth. In both cases if the core is not pre-provisioned, or no admission control is undertaken into the core then bottlenecks in the core cannot be prevented. The statement is therefore deployment specific and should be rectified. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 02:34:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18715 for ; Sat, 23 Mar 2002 02:33:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA16026 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 02:33:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13073; Sat, 23 Mar 2002 02:02:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13035 for ; Sat, 23 Mar 2002 02:02:12 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13146 for ; Sat, 23 Mar 2002 02:02:09 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Mar 2002 02:01:41 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46A962CB@ftmail> From: "Alan O'Neill" To: "David R. Oran" Cc: sip@ietf.org Subject: RE: [Sip] Re: Manyfolks Clarifications Date: Sat, 23 Mar 2002 02:01:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Dave, Fully appreciate this, and we can also note that in the case of pre-provisioned QoS the system uses my local 'QoS' SLA state and the forwarding of 'current' preconditions state to the peer to also speed things up. So I am certainly not arguing against end to end QoS signalling but I am trying to tease out other issues though with the use of a separate e2e tag, and specifically worried about some of the text and assumptions voiced about what a UA is assuming and how... I think it would be a lot preferable if we had one integrated status model and added supplementary tags to indicate that signalling feedback will be provided. This avoids the local/remote v e2e beauty contest and the inevitable risk in heterogeneous networks of multiple offers when the offerier assumes / chooses the wrong initial status model to a prefix they do not yet know, within commercial models that cannot guess (who pays for booking what) An integrated model has me booking my local, you booking your local, or either of us booking the others local by remote signalling. If I say I can book yours and it is not true, then the answering can come back and refuse my offer to remotely book and instead book its own..much better I feel. No beauty contest, no wild claims about core booking, just a negotiation of what is possible and who books what.. All the round trip gains are still fully available but the black holes are not.. See follow-up e-mail for details.. Thanks for trying to help us move forward on this, Alan. PS: By the way, the reason for the slow interactivity of this dialogue is that I am in Aus and have just moved house so apologies for the effect that is having in dragging this out.. -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: 23 March 2002 01:15 To: 'Gonzalo Camarillo'; 'Alan O'Neill' Cc: sip@ietf.org Subject: RE: [Sip] Re: Manyfolks Clarifications I believe the situation is much simpler than you are making out, and has nothing really to do with resource reservation, or QoS itself. Rather, it has to do with whether you can do a 1/2 round trip optimization in the call establishment state machine. To squeeze this out you need to distinguish two cases: 1) The other party has end-to-end admission control signaling, and hence I can use local state transitions of the QoS admission control machine I run with him to set the pre-condition satisfied state based on feedback in the QoS signaling from the other party. 2) The other party has only "local" admission control signaling, and hence I need to wait from them to explicitly tell me a precondition was satisfied before entering an alerting state, rather than inferring it as can be sometimes done in the end-to-end case. This is not some cosmic indicator about the nature of QoS; only an optimization knowing the nature of the other party's QoS signaling can provide. Dave > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Wednesday, March 20, 2002 11:57 PM > To: Alan O'Neill > Cc: sip@ietf.org > Subject: [Sip] Re: Manyfolks Clarifications > > > Hello, > > Alan O'Neill wrote: > > > The above discussion therefore suggests to me that all > preconditions > > must be assumed to be end to end, that the e2e tag for the QoS > > mechanism is useless because it can never be safely applied, and > > therefore that the e2e tag be removed. > > Look at the DCS architecture. They can be sure when they have > e2e QoS resources. And in my intranet, when my QoS > reservation protocol tells me that I have e2e QoS service, it > is because I have it. > > If you think that having e2e QoS is impossible, you should > provide feedback to a different WG. Not SIP. > > > > > The local/remote model is on the right path but I believe > incomplete. > > Essentially, the model should be that the MN has an SLA wrt > QoS with > > some limited scope (on-net, offnet to specific prefixes etc). The > > caller seeking preconditions simply adds in the Invite that that is > > the case, and will clearly only do so if believes it has a > candidate > > SLA at its end. > > Look at the 3GPP architecture. They have enough resources in > the backbone. The only thing that worries them is the radio > interface. With the local and remote tags they perform PDP > context activation... it works. > > > >but the UAs should still be able to reduce > > their preconditions to attempt a best effort call in these > >circumstances if they so desire. > > This is always possible. > > > > A related issue that I would like to raise is that given that the > > actual IP prefix of the callee is not known at the time of > the offer > > (and hence the caller neither actually knows if it does > have an SLA or > > a QoS mech for that callee prefix), it is critical that the > > preconditons be able to be flexibly adjusted in response to > additional > > information. > > > That's why you have the carry the current status in the SDP. > Because once you receive the first answer you can update it > (because you know the destination IP address)... and if you > required e2e QoS and after getting the remote IP address you > notice that it is impossible, you do not want to establish > the session, because your requirement cannot be fulfilled. If > you want, you can send a new offer without preconditions, but > the first offer/asnwer fails correctly, because your > preconditions could not be met. > > > I would therefore suggest > > that preconditions should be able to be increased or decreased at > > either end, and not just increased. > > You can always send new offers. The only place where you can > only upgrade the strength tag is within a single offer/answer > exchange. > > Thanks for your comments, > > Gonzalo > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 13:09:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23736 for ; Sat, 23 Mar 2002 13:09:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29670 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 13:09:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27238; Sat, 23 Mar 2002 12:53:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27197 for ; Sat, 23 Mar 2002 12:53:25 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23557 for ; Sat, 23 Mar 2002 12:53:22 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2NHqri18596; Sat, 23 Mar 2002 11:52:54 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2NHqrF18478; Sat, 23 Mar 2002 11:52:53 -0600 (CST) Received: from lmf.ericsson.se (rmt160127.am.ericsson.se [138.85.160.127]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA16080; Sat, 23 Mar 2002 11:52:51 -0600 (CST) Message-ID: <3C9CC1AF.92C9EA30@lmf.ericsson.se> Date: Sat, 23 Mar 2002 19:55:59 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: sip@ietf.org References: <8C92E23A3E87FB479988285F9E22BE46A962C4@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Alan, Alan O'Neill wrote: > > Page 7 top > > ' Note that the use of the segmented status-type does not > prevent bottlenecks in the backbone, only in the access > networks.' > > The wording here is inappropriate as it seems to suggest that e2e is somehow > different and more to the point better, than local /remote but this is > clearly not universally true. I find the wording perfectly OK. Again, you are confusing the QoS mechanism with the preconditions. Having local/remote preconditions does not prevent bottlenecks in the network. It may happen that you have a high bandwidth channel between both UAs, and it may happen that you have a low bandwidth link in the middle, but in both situations, this has nothing to do with the preconditions you use. Your local/remote preconditions do not tell you anything about the backbone. Using an e2e reservation protocol ensures you that there are network resources end to end. If the protocol does not work because it allows routers to claim that there is QoS when there is not, it is a problem of the reservation protocol. Not a problem of the preconditions. The idea of manyfolks is separating the reservation mechanism from the preconditions. If RSVP (or anu other e2e reservation protocol) does not work, you should send feedback to its authors, not to the authors of manyfolks. Thanks for your comments, Best regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 13:15:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23888 for ; Sat, 23 Mar 2002 13:15:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00478 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 13:15:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29043; Sat, 23 Mar 2002 13:04:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29001 for ; Sat, 23 Mar 2002 13:04:53 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23706 for ; Sat, 23 Mar 2002 13:04:50 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2NI4Fi19525; Sat, 23 Mar 2002 12:04:15 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2NI4EF19547; Sat, 23 Mar 2002 12:04:14 -0600 (CST) Received: from lmf.ericsson.se (rmt160127.am.ericsson.se [138.85.160.127]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA16892; Sat, 23 Mar 2002 12:04:12 -0600 (CST) Message-ID: <3C9CC458.7AD547F6@lmf.ericsson.se> Date: Sat, 23 Mar 2002 20:07:20 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: "'Alan O'Neill'" , sip@ietf.org Subject: Re: [Sip] Re: Manyfolks Clarifications References: <000301c1d208$57abc210$34ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, "David R. Oran" wrote: > This is not some cosmic indicator about the nature of QoS; only an > optimization knowing the nature of the other party's QoS signaling can > provide. > Exactly. That is the spirit of the draft. Separating the QoS, security of whatever mechanism you use to meet the preconditions from the information that needs to be carried in SIP in order to know when to proceed with session establishment. However, as Dave points out, the information to be carried in SIP depends on the mechanism used below. That's why we have both status types: segmented and e2e. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 16:16:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25353 for ; Sat, 23 Mar 2002 16:16:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25765 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 16:16:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22942; Sat, 23 Mar 2002 15:58:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22907 for ; Sat, 23 Mar 2002 15:58:23 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25124 for ; Sat, 23 Mar 2002 15:58:18 -0500 (EST) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2NKvpI6020175 for ; Sat, 23 Mar 2002 12:57:51 -0800 (PST) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACR92830; Sat, 23 Mar 2002 12:57:51 -0800 (PST) Date: Sat, 23 Mar 2002 12:55:29 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Options for P- header standardization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, A lot of people seemed to be concerned about the prospect of standardizing headers that had once been P- headers. I'd like to outline *all* the possibilites here, and then cover what I think are the pros and cons of each possibility. I'd also like to re-emphasize what I said at the microphone during the SIP session Wednesday. We expect that 99% of P- headers will never be standardized, so this problem is not so large as I think many have feared. Lets talk about standardization options for a "preliminary" header: P-Foo 1) Just register P-Foo as a Proposed Standard 2) Register Foo as a Proposed Standard and always send/receive both headers 3) Register Foo as a Proposed Standard with a new option tag 4) Register Bar as a Proposed Standard and always send/receive both headers 5) Register Bar as a Proposed Standard with a new option tag 6) Just send/receive Foo or Bar, immediately deprecate P-Foo 1) Defeats the point of P- headers in the first place, because the whole point in having the P- header space is to allow folks to easily identify which headers are not "standard". 2) and 4) may provide some duplicate some information (wastes bandwidth) but insures the correct behavior. You just need to be sure to ignore P-Foo if you support and receive Foo or Bar. 3) and 5) present the same problem that we have with any new standard header. 6) Is only reasonable if the implementation and deployment of P-Foo was limited. hope this helps. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 17:12:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25762 for ; Sat, 23 Mar 2002 17:12:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04879 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 17:12:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02096; Sat, 23 Mar 2002 16:58:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02065 for ; Sat, 23 Mar 2002 16:58:01 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25688 for ; Sat, 23 Mar 2002 16:57:56 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA13781; Sat, 23 Mar 2002 16:57:54 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2NLvsPm018802 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 23 Mar 2002 16:57:54 -0500 (EST) Message-ID: <3C9CFA46.547B559B@cs.columbia.edu> Date: Sat, 23 Mar 2002 15:57:26 -0600 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: Rohan Mahy Subject: Re: [Sip] Options for P- header standardization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan, thanks for the first summary. I think there are two separable issues: (1) Label registrations (with IANA) with their type (e.g., Informational or modifying) (2) Make the header label reflect this fact (i.e., using the P- prefix). My basic thesis is that option (1) is sufficient and architecturally cleaner. Since option (2) has a number of problems, it would seem that the proponents of such approach (2) have to identify its merits. The current SIP change draft does not provide any such reasoning that I could find. Some points to consider: - We should be very careful to distinguish option tags and header names. This can get a bit confusing, since some of the proposed (but, I believe, never standardized) mechanisms for HTTP extensions made a very different choice. The important part is that there is *absolutely no* fixed relationship between option tags and header field names. Option tags identify behavior, not field names. Thus, there can be option tags that rely on zero new header fields, or on some combination of existing headers. It is quite possible that a standards-track feature (with an option tag) defined later may want to rely on some informational header, possibly in combination with a new non-P header, thus forcing renaming or duplication. In the latter case, renaming P-Foo to Foo is not appropriate, since the original behavior is still valid. Thus, only duplication of information is possible. - In case there's a doubt about the difference between header names and feature names, remember that only feature names can be used for negotiation. SIP has no mechanism to say "Dear UAC, I don't support header H", only "Dear UAC, I don't support feature F". Thus, any design that relies on the presence of new headers (beyond the basic mandatory headers like To/From/Call-ID/CSeq, etc.) without a feature tag is plain a broken design and cannot work in practice. - I think there was agreement in the discussion that an implementation could not and MUST NOT derive any useful knowledge from the fact that a header started with the two characters "P-". It seems architecturally unsound to include information that should never appear in code. We don't include in the header which methods it can appear with, either... There doesn't seem to be a precedent for such a labeling mechanism, as far as I can tell. The closest I can think of is the early Fortran IV convention of labeling integers with variable names starting with I through N (?), but from all I've heard, that's not exactly considered state-of-the-art any more. - If we were to decide to include both P- and non-P versions in a header could be extremely expensive. Header fields can have unbounded length. This is particularly true for "informational" headers since they often contain information generated by or for humans. - There are a number of existing headers that behave like P- headers, yet don't have the name. Thus, in practice, one has to look at the relevant spec in any event to figure out what behavior is triggered by the header. - If we don't rename a P- header when it becomes part of a named feature, the whole notion of identifying headers has been lost. I'm afraid I just don't understand what technical problem we're trying to solve by including information that implementations cannot use in the name of a field. We can solve the problem of preventing non-standards-track header fields causing protocol behavior changes by ruling out the use of option tags in any such documents. That is simple and easily verifiable. In addition, with or without the P- prefix, somebody has to look at the document and verify that the specification doesn't call for substantial behavioral changes in SIP behavior. The prefix doesn't help at all in that analysis. My suggestion: (1) Label any SIP change drafts clearly, possibly in the title (as in, e.g., "SIP Feature for ..." vs. "SIP Informational Enhancement for ..."). Include some kind of reference text template in the draft to alert the reader. ("This draft follows Section 5 of sip-change-rfc and defines behavior and headers that are ..."). The naming convention for RTP payload type definitions is a precedence for such a draft naming convention. (2) The IANA registration should clearly identify the type of behavior. (3) Make sure that the presence of option tags in each extension is defined by the change spec. (I think it is reasonably clear, but some additional motivation wouldn't hurt.) Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 17:53:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26144 for ; Sat, 23 Mar 2002 17:53:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA11495 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 17:53:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09286; Sat, 23 Mar 2002 17:38:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09250 for ; Sat, 23 Mar 2002 17:38:15 -0500 (EST) Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26014 for ; Sat, 23 Mar 2002 17:38:09 -0500 (EST) Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66]) by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2NMc5d08799; Sat, 23 Mar 2002 16:38:05 -0600 (CST) From: "Ben Campbell" To: "Henning Schulzrinne" , Cc: "Rohan Mahy" Subject: RE: [Sip] Options for P- header standardization Date: Sat, 23 Mar 2002 16:38:02 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C9CFA46.547B559B@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have to agree with Henning. All the options that Rohan listed result in one of three things: 1) You can't really know that a header is non-standard unless you look up the RFC/IANA registration. 2) All implementations must support 2 possible header names for the same thing 3) No backwards compatibility to pre-standard implementations. Of these 3, the least damaging appears to be result #1. This is identical to the result of not bothering with the "p" prefix in the first place. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Henning > Schulzrinne > Sent: Saturday, March 23, 2002 3:57 PM > To: sip@ietf.org > Cc: Rohan Mahy > Subject: Re: [Sip] Options for P- header standardization > > > Rohan, thanks for the first summary. > > I think there are two separable issues: > > (1) Label registrations (with IANA) with their type (e.g., Informational > or modifying) > > (2) Make the header label reflect this fact (i.e., using the P- prefix). > > My basic thesis is that option (1) is sufficient and architecturally > cleaner. Since option (2) has a number of problems, it would seem that > the proponents of such approach (2) have to identify its merits. The > current SIP change draft does not provide any such reasoning that I > could find. > > Some points to consider: > > - We should be very careful to distinguish option tags and header names. > This can get a bit confusing, since some of the proposed (but, I > believe, never standardized) mechanisms for HTTP extensions made a very > different choice. > > The important part is that there is *absolutely no* fixed relationship > between option tags and header field names. Option tags identify > behavior, not field names. Thus, there can be option tags that rely on > zero new header fields, or on some combination of existing headers. It > is quite possible that a standards-track feature (with an option tag) > defined later may want to rely on some informational header, possibly in > combination with a new non-P header, thus forcing renaming or > duplication. > > In the latter case, renaming P-Foo to Foo is not appropriate, since the > original behavior is still valid. Thus, only duplication of information > is possible. > > - In case there's a doubt about the difference between header names and > feature names, remember that only feature names can be used for > negotiation. SIP has no mechanism to say "Dear UAC, I don't support > header H", only "Dear UAC, I don't support feature F". Thus, any design > that relies on the presence of new headers (beyond the basic mandatory > headers like To/From/Call-ID/CSeq, etc.) without a feature tag is plain > a broken design and cannot work in practice. > > - I think there was agreement in the discussion that an implementation > could not and MUST NOT derive any useful knowledge from the fact that a > header started with the two characters "P-". It seems architecturally > unsound to include information that should never appear in code. We > don't include in the header which methods it can appear with, either... > > There doesn't seem to be a precedent for such a labeling mechanism, as > far as I can tell. The closest I can think of is the early Fortran IV > convention of labeling integers with variable names starting with I > through N (?), but from all I've heard, that's not exactly considered > state-of-the-art any more. > > - If we were to decide to include both P- and non-P versions in a header > could be extremely expensive. Header fields can have unbounded length. > This is particularly true for "informational" headers since they often > contain information generated by or for humans. > > - There are a number of existing headers that behave like P- headers, > yet don't have the name. Thus, in practice, one has to look at the > relevant spec in any event to figure out what behavior is triggered by > the header. > > - If we don't rename a P- header when it becomes part of a named > feature, the whole notion of identifying headers has been lost. > > I'm afraid I just don't understand what technical problem we're trying > to solve by including information that implementations cannot use in the > name of a field. We can solve the problem of preventing > non-standards-track header fields causing protocol behavior changes by > ruling out the use of option tags in any such documents. That is simple > and easily verifiable. In addition, with or without the P- prefix, > somebody has to look at the document and verify that the specification > doesn't call for substantial behavioral changes in SIP behavior. The > prefix doesn't help at all in that analysis. > > My suggestion: > > (1) Label any SIP change drafts clearly, possibly in the title (as in, > e.g., "SIP Feature for ..." vs. "SIP Informational Enhancement for > ..."). Include some kind of reference text template in the draft to > alert the reader. ("This draft follows Section 5 of sip-change-rfc and > defines behavior and headers that are ..."). > > The naming convention for RTP payload type definitions is a precedence > for such a draft naming convention. > > (2) The IANA registration should clearly identify the type of behavior. > > (3) Make sure that the presence of option tags in each extension is > defined by the change spec. (I think it is reasonably clear, but some > additional motivation wouldn't hurt.) > > Henning > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 18:31:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26437 for ; Sat, 23 Mar 2002 18:31:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA17692 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 18:31:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16077; Sat, 23 Mar 2002 18:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16035 for ; Sat, 23 Mar 2002 18:21:54 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26363 for ; Sat, 23 Mar 2002 18:21:50 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA22470; Sat, 23 Mar 2002 18:21:49 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2NNLmPm020780 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 23 Mar 2002 18:21:49 -0500 (EST) Message-ID: <3C9D0DF1.DB2A2EC0@cs.columbia.edu> Date: Sat, 23 Mar 2002 17:21:21 -0600 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: sip@ietf.org, Rohan Mahy Subject: Re: [Sip] Options for P- header standardization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit To add to this, it seems experience teaches us that the standardization status of a draft is subject to changes very late in the game, for any number of reasons. A non-exhaustive list includes: - IPR issues that pop up at any point and then argue for "demotion" to informational; as participants of this working group know, this isn't exactly a theoretical case. - IESG concerns that only appear after last call; - external reference issues ("organization X needs a standards-track RFC for a normative reference"). Depending on the direction, suddenly a P- header needs to drop the prefix or a non-P header needs to acquire it, leading to the duplication of headers or breaking of existing implementations. SIP itself saw a fair bit of implementation before the RFC came out, with the first bake-off tests with dozens of implementations being done weeks after the RFC. Unless we want to switch to an ITU model ("thou must not implement before the spec has been stenciled on parchment"), we need to provide some good-faith protection to implementors. Obviously, there can be no guarantee of backwards-compatibility if the reason has sufficient technical merit, but I find it hard to tell an implementor with a straight face that their shipping product is broken because of some unpredictable external forces, not because of any technical flaws. Unless we are becoming completely legalistic, expediency and good-faith protection will lead us to make exceptions, which then further erodes any significance of the designator. To add another reason why duplicate headers are bad: Logging becomes a pain. The logging logic now needs to know that it should log only one of the header instances, as otherwise any searching or sorting gets even more painful. Yet another one: sip-cgi, SIP servlet and CPL logic gets bloated, since I now need to check two header names in all comparisons. People will forget to do this, and suddenly scripts go erratic in subtle ways. Also, as soon as you have two headers with the same function but different names, any headers where proxies add instances (as in Via) require elaborate logic and become extremely brittle. Let's say a proxy only knows about the non-P header and adds an instance to it. It doesn't know about the P-header. (Doesn't really matter which way the proxy tends.) Suddenly, the UAS gets two headers that are supposed to be the same, but aren't. Duh. Another brittleness: Headers that are included in both the S/MIME-protected body and the outer header. Again, elaborate logic is needed to reconcile the P-/non-P headers. I suspect that there any number of other things that could break. People have suggested getting rid of the compact headers; all of the reasons offered apply in spades here. Indeed, if we allow headers to acquire or drop prefixes, most of the same arguments would lead one to think that adding compact forms later on would be a good idea. I grant that any of these problems identified can be fixed individually, at significant spec bloat. (Plus, it seems a little late to do this now that the RFC has shipped. Thus, suddenly 'bis' implementations are all broken.) This, I think, is an example of "aliasing", which is always a rather dangerous concept, starting from Fortran COMMONs in the 1960s to pointer aliasing in C/C++. Thus, I suggest that people proposing duplicating header fields have a fairly high standard of proof that they need to meet as to why there is no other solution and what the benefits might be. Henning Ben Campbell wrote: > > I have to agree with Henning. > > All the options that Rohan listed result in one of three things: > > 1) You can't really know that a header is non-standard unless you look up > the RFC/IANA registration. > 2) All implementations must support 2 possible header names for the same > thing > 3) No backwards compatibility to pre-standard implementations. > > Of these 3, the least damaging appears to be result #1. > > This is identical to the result of not bothering with the "p" prefix in the > first place. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 19:28:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26817 for ; Sat, 23 Mar 2002 19:28:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26471 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 19:28:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23708; Sat, 23 Mar 2002 19:10:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23676 for ; Sat, 23 Mar 2002 19:10:03 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26710 for ; Sat, 23 Mar 2002 19:10:00 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Mar 2002 19:09:32 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C372CF@ftmail> From: "Alan O'Neill" To: "'David R. Oran '" Cc: "'sip@ietf.org '" Date: Sat, 23 Mar 2002 19:09:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Manyfolks: Unified local/remote model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dave, Here is one way to view local/remote and e2e which I believe better supports inter-domain preconditions. This is through the removal of the two distinct status types because they are a barrier to efficient offer/answer negotiation between heterogeneous domains, specifically because you need to use a new offer if a UA starts with the wrong status type. It also requires two sets of processing rules which is unnecessarily complex and avoids the e2e v segmented beauty contest..It certainly is not a design though just a way to represent the ideas. As before, all preconditions should be assumed to be a request for end to end resources in the direction indicated by the direction tag. As before all preconditions requests are e2e in nature but the QoS mechanisms supporting these may not be. The current status reflects where we are compared to the desired status. Offerer offers, the answerer answers, and Update is used where necessary for confirmation. Precondition directions as always are wrt to the SDP sender But lets instead use nill, local, remote and localremote where localremote implies the availability of an end to end QoS protocol. From the view of two UAs, localremote is as much as we can negotiate as neither UA knows anything about the core in reality, even with an end to end protocol. The offerer follows manyfolks-05 and selects between nill, local, remote, localremote as to its desired status towards meeting preconditions in the specific direction. The answerer can then select from the offered desired status and can specifically choose a subset or move from segmented to e2e models. This is achieved by both the desired status and strength being negotiable with the answerer responding to the offerer. Lets assume for direction caller(offerer) to callee(answerer) we have an optional precondition. caller sends a=des:qos optional X send callee sends a=des:qos optional Y recv Note that both ends keep there own view of what they have to do to meet precondition so offerer/answerer des lines are different in each direction. For below note RSVP is used as one example of a protocol giving feedback).. Actual Actual Offered X Answered Y Meaning nill nill Nothing will be booked local Answerer happy to book its end remote Answerer books other end using RSVP but local RSVP not supported. localremote eg e2e via e2e signalling eg RSVP attempted by answerer for both ends local nill Answerer won't book anything, offerer can local e2e via segmented model remote Answerer will book resources using say RSVP localremote e2e via e2e signalling eg RSVP attempted by answerer for both ends remote nill Anwerer won't book anything,left to offerer local Answerer happy to book its end remote Inverse segmented - each doing other ends QoS (maybe for policy reasons ?) localremote e2e via e2e signalling eg RSVP attempted by answerer for both ends localremote nill Happy for offerer to do e2e via e2e signaling local Switch to segmented model with each doing local remote switch to inverse segmented model (each doing the others end) localremote answerer over-rules and wishes to book Of course the answerer can also respond with 'none' strength to cancel the offered precondition, or stengthen it to 'mandatory' to tighten the requirement for the desired status for the offerer. The offerers SDP should now reflect the change requested by the answerer and no additional desired status negotiation is possible through updates, which only affect current status (I think that is optimal) Now at this point both ends know what needs to be done, and by whom..If offerer is not happy it can re-offer or end the call-leg. Otherwise we move to the current-status aspects... The current-status of the offerer will limit the flexibility open to the answerer, in its response to the offered desired status, by including information indicating that the offerer is starting the booking of, or announcing the availability of, resources matching the offerers desired status. The answerer should not modify the desired status by contravening the current status of the offerer. The current status and each end then moves towards the desired status. The callee should not alert until the preconditions are met and the caller should send an Update when it learns additional information not known to the callee about the current status via changes in its local booking and its booking of remote resources, whether as part of a segmented, inverse segmented or end to end signalling model. I hope I having missed anything and that the addition of an integrated local, remote, localremote model eliminates two competing approaches and the risk of the offerer starting with the wrong model. I hope I haven't missed anything but this is kin of where I was going with my analysis... Alan. ---------------------------------------------------------------- Notice Regarding Intellectual Property Rights Flarion's submissions will conform with RFC 2026. Flarion may seek patent protection on some or all of the technical information submitted by its employees in connection with the IETF's standards process. If part(s) of a submission by Flarion is (are) included in a standard and Flarion owns patent(s) and/or pending patent application(s) that are essential to implementation of such included part(s) in said standard, Flarion is prepared to grant a license on fair, reasonable, reciprocal (license back) and non-discriminatory terms on such included part(s). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 19:43:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26965 for ; Sat, 23 Mar 2002 19:43:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29334 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 19:43:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26936; Sat, 23 Mar 2002 19:30:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26878 for ; Sat, 23 Mar 2002 19:30:17 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26847 for ; Sat, 23 Mar 2002 19:30:15 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Mar 2002 19:29:47 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C372D0@ftmail> From: "Alan O'Neill" To: "'Gonzalo Camarillo '" , "Alan O'Neill" Cc: "'sip@ietf.org '" Date: Sat, 23 Mar 2002 19:29:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org And that is the problem Gonzalo, You keep stating that using an e2e protocol guarantees end to end resources but that is not necessarily true. Only end to end protocol in all congestable elements assures that. If the e2e protocol has a preprovisioned core then so can the segmented model.. e2e is not better than segmented per say.. Original Message----- From: Gonzalo Camarillo To: Alan O'Neill Cc: sip@ietf.org Sent: 23/03/02 12:55 Subject: Re: Manyfolks draft wording Hello Alan, [pAlan O'Neill wrote:> > Page 7 top > > ' Note that the use of the segmented status-type does not > prevent bottlenecks in the backbone, only in the access > networks.' > > The wording here is inappropriate as it seems to suggest that e2e is somehow > different and more to the point better, than local /remote but this is > clearly not universally true. I find the wording perfectly OK. Again, you are confusing the QoS mechanism with the preconditions. Having local/remote preconditions does not prevent bottlenecks in the network. It may happen that you have a high bandwidth channel between both UAs, and it may happen that you have a low bandwidth link in the middle, but in both situations, this has nothing to do with the preconditions you use. Your local/remote preconditions do not tell you anything about the backbone. Using an e2e reservation protocol ensures you that there are network resources end to end. If the protocol does not work because it allows routers to claim that there is QoS when there is not, it is a problem of the reservation protocol. Not a problem of the preconditions. The idea of manyfolks is separating the reservation mechanism from the preconditions. If RSVP (or anu other e2e reservation protocol) does not work, you should send feedback to its authors, not to the authors of manyfolks. Thanks for your comments, Best regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 19:48:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27029 for ; Sat, 23 Mar 2002 19:48:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00084 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 19:48:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28212; Sat, 23 Mar 2002 19:36:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28183 for ; Sat, 23 Mar 2002 19:36:34 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26913 for ; Sat, 23 Mar 2002 19:36:31 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Mar 2002 19:36:03 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C372D4@ftmail> From: "Alan O'Neill" To: "'Gonzalo Camarillo '" , "'David R. Oran '" Cc: "Alan O'Neill" , "'sip@ietf.org '" Subject: RE: [Sip] Re: Manyfolks Clarifications Date: Sat, 23 Mar 2002 19:36:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The useful of carrying the info is not in doubt, only the interpretation and the separate status tags... -----Original Message----- From: Gonzalo Camarillo To: David R. Oran Cc: 'Alan O'Neill'; sip@ietf.org Sent: 23/03/02 13:07 Subject: Re: [Sip] Re: Manyfolks Clarifications Hi, "David R. Oran" wrote: > This is not some cosmic indicator about the nature of QoS; only an > optimization knowing the nature of the other party's QoS signaling can > provide. > Exactly. That is the spirit of the draft. Separating the QoS, security of whatever mechanism you use to meet the preconditions from the information that needs to be carried in SIP in order to know when to proceed with session establishment. However, as Dave points out, the information to be carried in SIP depends on the mechanism used below. That's why we have both status types: segmented and e2e. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 23 20:32:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27415 for ; Sat, 23 Mar 2002 20:32:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07885 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 20:32:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05281; Sat, 23 Mar 2002 20:20:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05240 for ; Sat, 23 Mar 2002 20:20:51 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27257 for ; Sat, 23 Mar 2002 20:20:48 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2O1KDi20851; Sat, 23 Mar 2002 19:20:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2O1KDm18201; Sat, 23 Mar 2002 19:20:13 -0600 (CST) Received: from lmf.ericsson.se (rmt160149.am.ericsson.se [138.85.160.149]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA18332; Sat, 23 Mar 2002 19:20:11 -0600 (CST) Message-ID: <3C9D2A78.16970331@lmf.ericsson.se> Date: Sun, 24 Mar 2002 03:23:04 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'David R. Oran '" , "'sip@ietf.org '" Subject: Re: [Sip] Re: Manyfolks Clarifications References: <8C92E23A3E87FB479988285F9E22BE46C372D4@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, As we stated in previous mails, different resource reservation mechanism need different information in the signalling plane (i.e., SIP). That's why there are two tags. About their usefulness, both tags, local/remote and e2e, are used in different real-life architectures: DCS (e2e) and 3GPP (local/remote). Regards, Gonzalo Alan O'Neill wrote: > > The useful of carrying the info is not in doubt, only the interpretation > and the separate status tags... > > -----Original Message----- > From: Gonzalo Camarillo > To: David R. Oran > Cc: 'Alan O'Neill'; sip@ietf.org > Sent: 23/03/02 13:07 > Subject: Re: [Sip] Re: Manyfolks Clarifications > > Hi, > > "David R. Oran" wrote: > > > This is not some cosmic indicator about the nature of QoS; only an > > optimization knowing the nature of the other party's QoS signaling can > > provide. > > > > Exactly. That is the spirit of the draft. Separating the QoS, security > of whatever mechanism you use to meet the preconditions from the > information that needs to be carried in SIP in order to know when to > proceed with session establishment. However, as Dave points out, the > information to be carried in SIP depends on the mechanism used below. > That's why we have both status types: segmented and e2e. > > Regards, > > Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Sat Mar 23 20:38:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27626 for ; Sat, 23 Mar 2002 20:38:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09451 for sip-archive@odin.ietf.org; Sat, 23 Mar 2002 20:38:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06359; Sat, 23 Mar 2002 20:27:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06320 for ; Sat, 23 Mar 2002 20:27:55 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27305 for ; Sat, 23 Mar 2002 20:27:51 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2O1Rsl28480; Sat, 23 Mar 2002 19:27:54 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2O1Rrx29962; Sat, 23 Mar 2002 19:27:53 -0600 (CST) Received: from lmf.ericsson.se (rmt160149.am.ericsson.se [138.85.160.149]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA18918; Sat, 23 Mar 2002 19:27:52 -0600 (CST) Message-ID: <3C9D2C44.52BF41C6@lmf.ericsson.se> Date: Sun, 24 Mar 2002 03:30:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'sip@ietf.org '" References: <8C92E23A3E87FB479988285F9E22BE46C372D0@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Alan O'Neill wrote: > You keep stating that using an e2e protocol guarantees end to end resources > but that is not necessarily true. as I have already stated, if you think that e2e reservation protocols do not ensure e2e QoS, you should provide your feedback to a working group that is chartered to develop e2e reservation protocols. Not to SIP. The fact is that, when you use e2e reservation protocols, you need certain information in the signalling plane. This information is different when you use a reservation protocol only in the accesses. Different tags ensure that SIP carries the information needed by the resource reservation mechanism in use. If you think that people should not be using e2e reservation protocols because they do not work, you should address your feedback to the persons developing network architectures. Not to SIP. > e2e is not better than segmented per say.. Who said that e2e is better or worse than segmented? They are just different because they apply to different scenarios. If you think that one of them is always better than the other, you should address your feedback to a working group developing resource reservation protocols. Not to SIP. This way they would not lose their time on something that is clearly worse than another already existing mechanism. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Mar 24 23:37:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24863 for ; Sun, 24 Mar 2002 23:37:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA23610 for sip-archive@odin.ietf.org; Sun, 24 Mar 2002 23:37:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA18881; Sun, 24 Mar 2002 23:16:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA18838 for ; Sun, 24 Mar 2002 23:16:34 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24321 for ; Sun, 24 Mar 2002 23:16:29 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2P4FrI16986; Sun, 24 Mar 2002 20:15:53 -0800 (PST) Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACK49419; Sun, 24 Mar 2002 20:16:13 -0800 (PST) From: "Cullen Jennings" To: "Ben Campbell" , "Henning Schulzrinne" , Cc: "Rohan Mahy" Subject: RE: [Sip] Options for P- header standardization Date: Sun, 24 Mar 2002 20:18:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I want all the people who think it is ok to change the p-foo header to foo as it becomes standard to go and change the MESSAGE message to some less messy message name for a message. Seriously, please make it clear why this is significantly different. Ben and Henning are making sense to me. A few points about Ben's 3 options below. In option 1, I am fine having to look it up in a RFC or IANA to find out what type of standard it is. I am going to have to do this anyway. I see no requirement to code the type of the standard on the wire. Option 2 is more of a bummer than it might seem at first glance. It's fine for everyone to receive both, but what should I send? In practice I will probably just send the p- version because it has better odds of working during the transition phase (which could last a *long* time). Considering the track record of SIP having significant deployed equipment running stuff that is not RFC yet, option 3 is not that appealing when it can be so easily avoided. Why make interoperability any harder than it needs to be? Cullen > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Ben > Campbell > Sent: Saturday, March 23, 2002 2:38 PM > To: Henning Schulzrinne; sip@ietf.org > Cc: Rohan Mahy > Subject: RE: [Sip] Options for P- header standardization > > > I have to agree with Henning. > > All the options that Rohan listed result in one of three things: > > 1) You can't really know that a header is non-standard unless you look up > the RFC/IANA registration. > 2) All implementations must support 2 possible header names for the same > thing > 3) No backwards compatibility to pre-standard implementations. > > Of these 3, the least damaging appears to be result #1. > > This is identical to the result of not bothering with the "p" > prefix in the > first place. > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Henning > > Schulzrinne > > Sent: Saturday, March 23, 2002 3:57 PM > > To: sip@ietf.org > > Cc: Rohan Mahy > > Subject: Re: [Sip] Options for P- header standardization > > > > > > Rohan, thanks for the first summary. > > > > I think there are two separable issues: > > > > (1) Label registrations (with IANA) with their type (e.g., Informational > > or modifying) > > > > (2) Make the header label reflect this fact (i.e., using the P- prefix). > > > > My basic thesis is that option (1) is sufficient and architecturally > > cleaner. Since option (2) has a number of problems, it would seem that > > the proponents of such approach (2) have to identify its merits. The > > current SIP change draft does not provide any such reasoning that I > > could find. > > > > Some points to consider: > > > > - We should be very careful to distinguish option tags and header names. > > This can get a bit confusing, since some of the proposed (but, I > > believe, never standardized) mechanisms for HTTP extensions made a very > > different choice. > > > > The important part is that there is *absolutely no* fixed relationship > > between option tags and header field names. Option tags identify > > behavior, not field names. Thus, there can be option tags that rely on > > zero new header fields, or on some combination of existing headers. It > > is quite possible that a standards-track feature (with an option tag) > > defined later may want to rely on some informational header, possibly in > > combination with a new non-P header, thus forcing renaming or > > duplication. > > > > In the latter case, renaming P-Foo to Foo is not appropriate, since the > > original behavior is still valid. Thus, only duplication of information > > is possible. > > > > - In case there's a doubt about the difference between header names and > > feature names, remember that only feature names can be used for > > negotiation. SIP has no mechanism to say "Dear UAC, I don't support > > header H", only "Dear UAC, I don't support feature F". Thus, any design > > that relies on the presence of new headers (beyond the basic mandatory > > headers like To/From/Call-ID/CSeq, etc.) without a feature tag is plain > > a broken design and cannot work in practice. > > > > - I think there was agreement in the discussion that an implementation > > could not and MUST NOT derive any useful knowledge from the fact that a > > header started with the two characters "P-". It seems architecturally > > unsound to include information that should never appear in code. We > > don't include in the header which methods it can appear with, either... > > > > There doesn't seem to be a precedent for such a labeling mechanism, as > > far as I can tell. The closest I can think of is the early Fortran IV > > convention of labeling integers with variable names starting with I > > through N (?), but from all I've heard, that's not exactly considered > > state-of-the-art any more. > > > > - If we were to decide to include both P- and non-P versions in a header > > could be extremely expensive. Header fields can have unbounded length. > > This is particularly true for "informational" headers since they often > > contain information generated by or for humans. > > > > - There are a number of existing headers that behave like P- headers, > > yet don't have the name. Thus, in practice, one has to look at the > > relevant spec in any event to figure out what behavior is triggered by > > the header. > > > > - If we don't rename a P- header when it becomes part of a named > > feature, the whole notion of identifying headers has been lost. > > > > I'm afraid I just don't understand what technical problem we're trying > > to solve by including information that implementations cannot use in the > > name of a field. We can solve the problem of preventing > > non-standards-track header fields causing protocol behavior changes by > > ruling out the use of option tags in any such documents. That is simple > > and easily verifiable. In addition, with or without the P- prefix, > > somebody has to look at the document and verify that the specification > > doesn't call for substantial behavioral changes in SIP behavior. The > > prefix doesn't help at all in that analysis. > > > > My suggestion: > > > > (1) Label any SIP change drafts clearly, possibly in the title (as in, > > e.g., "SIP Feature for ..." vs. "SIP Informational Enhancement for > > ..."). Include some kind of reference text template in the draft to > > alert the reader. ("This draft follows Section 5 of sip-change-rfc and > > defines behavior and headers that are ..."). > > > > The naming convention for RTP payload type definitions is a precedence > > for such a draft naming convention. > > > > (2) The IANA registration should clearly identify the type of behavior. > > > > (3) Make sure that the presence of option tags in each extension is > > defined by the change spec. (I think it is reasonably clear, but some > > additional motivation wouldn't hurt.) > > > > Henning > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 07:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07204 for ; Mon, 25 Mar 2002 07:04:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06171 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 07:04:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00015; Mon, 25 Mar 2002 06:38:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29962 for ; Mon, 25 Mar 2002 06:37:58 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06931 for ; Mon, 25 Mar 2002 06:37:57 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 06:37:27 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C399B9@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: "'sip@ietf.org '" Date: Mon, 25 Mar 2002 06:37:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Gonzalo, I hope this is simply the result of language difficulties... I stated that "e2e reservations do not 'necessarily' ensure end to end QoS". This naturally implies that they can, but not always do, ensure end to end QoS. They ensure it when every pinch-point between the two endpoints process the e2e QoS signalling, undertake admission control and book sufficient resources for the flow. They do not in anyway ensure it when only the two end points run the e2e protocol but none of the routers do (the general Internet today). Some middle ground whereby the access does and the core doesn't process the end to end signalling is the common case and then the core does not ensure QoS, it merely provides some statistic possibility of there being resources based on the operator dimensioning, commensurate with the SLA with customers and between providers. In the manyfolks draft and in your follow-up to my wording issue you state that segmented does not ensure QoS whilst e2e protocol does. Thereby you are stating that segmented is somehow less able to satisfy preconditions and hence, according to my concern, is considered worse in this specific regard. The draft should leave the subject, and relative merits, of how operators provide and ensure QoS to them. They can use pre-provisioned, segmented, e2e and combinations, with suitable dimensioning risks (call blocking v call degradation probabilities) for the commercial model. e2e does have characteristics that are different and beneficial in some respects at the cost of running signalling. One such benefit was raised by Dave Oran and there are others...but that is not the point at hand. Please remove the misleading and frankly incorrect text. Alan. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 24 March 2002 01:31 To: Alan O'Neill Cc: 'sip@ietf.org ' Subject: Re: Manyfolks draft wording Hello, Alan O'Neill wrote: > You keep stating that using an e2e protocol guarantees end to end resources > but that is not necessarily true. as I have already stated, if you think that e2e reservation protocols do not ensure e2e QoS, you should provide your feedback to a working group that is chartered to develop e2e reservation protocols. Not to SIP. The fact is that, when you use e2e reservation protocols, you need certain information in the signalling plane. This information is different when you use a reservation protocol only in the accesses. Different tags ensure that SIP carries the information needed by the resource reservation mechanism in use. If you think that people should not be using e2e reservation protocols because they do not work, you should address your feedback to the persons developing network architectures. Not to SIP. > e2e is not better than segmented per say.. Who said that e2e is better or worse than segmented? They are just different because they apply to different scenarios. If you think that one of them is always better than the other, you should address your feedback to a working group developing resource reservation protocols. Not to SIP. This way they would not lose their time on something that is clearly worse than another already existing mechanism. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 07:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07220 for ; Mon, 25 Mar 2002 07:04:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06196 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 07:04:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00081; Mon, 25 Mar 2002 06:38:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00034 for ; Mon, 25 Mar 2002 06:38:02 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06933 for ; Mon, 25 Mar 2002 06:38:01 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 06:37:32 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C399BA@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo , "Alan O'Neill" Cc: "'sip@ietf.org '" Subject: RE: [Sip] Re: Manyfolks Clarifications Date: Mon, 25 Mar 2002 06:37:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Then what should a DCS UA use to a 3G UA and visaversa ? And what should DCS and 3G use to an existing Internet host (say connected to Worldcom), and visaversa ? These are where the fun starts Gonzalo.. Alan. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 24 March 2002 01:23 To: Alan O'Neill Cc: 'David R. Oran '; 'sip@ietf.org ' Subject: Re: [Sip] Re: Manyfolks Clarifications Hello, As we stated in previous mails, different resource reservation mechanism need different information in the signalling plane (i.e., SIP). That's why there are two tags. About their usefulness, both tags, local/remote and e2e, are used in different real-life architectures: DCS (e2e) and 3GPP (local/remote). Regards, Gonzalo Alan O'Neill wrote: > > The useful of carrying the info is not in doubt, only the interpretation > and the separate status tags... > > -----Original Message----- > From: Gonzalo Camarillo > To: David R. Oran > Cc: 'Alan O'Neill'; sip@ietf.org > Sent: 23/03/02 13:07 > Subject: Re: [Sip] Re: Manyfolks Clarifications > > Hi, > > "David R. Oran" wrote: > > > This is not some cosmic indicator about the nature of QoS; only an > > optimization knowing the nature of the other party's QoS signaling can > > provide. > > > > Exactly. That is the spirit of the draft. Separating the QoS, security > of whatever mechanism you use to meet the preconditions from the > information that needs to be carried in SIP in order to know when to > proceed with session establishment. However, as Dave points out, the > information to be carried in SIP depends on the mechanism used below. > That's why we have both status types: segmented and e2e. > > Regards, > > Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Mon Mar 25 08:30:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09444 for ; Mon, 25 Mar 2002 08:30:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27062 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 08:30:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21961; Mon, 25 Mar 2002 08:10:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21919 for ; Mon, 25 Mar 2002 08:10:29 -0500 (EST) Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08411 for ; Mon, 25 Mar 2002 08:10:27 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C897B4CE1A; Mon, 25 Mar 2002 08:10:28 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA10077; Mon, 25 Mar 2002 08:10:24 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA17027; Mon, 25 Mar 2002 08:09:21 -0500 (EST) Date: Mon, 25 Mar 2002 08:09:21 -0500 (EST) Message-Id: <200203251309.IAA17027@fish.research.att.com> To: sip@ietf.org Cc: hgs@cs.columbia.edu, bcampbell@dynamicsoft.com, rohan@cisco.com Subject: Re: [Sip] Options for P- header standardization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org For the sake of interoperability, it seems that every receiver must immediately strip the "P-" prefix from every header received in a message before processing it. Senders then use "best available information" at the time of shipping to decide whether to convert "Foo" to "P-Foo". (General rule: Be strict in what you send, generous in what you accept). This is the only way of solving the messy problem of keeping the P-Via headers combined and in order with the Via headers. So if those two rules are followed, (1) we get interoperability, and (2) the P- prefix is meaningless. I think these two go together. Changing the header name midway through the standardization process is a deliberate attempt to break early implementations. This tactic is seen in other standards bodies; hopefully IETF won't go that route. Since the whole point of the IANA registration is to avoid name clashes, waiting until publication as an RFC is way too late. The registration needs to happen with the individual's -00 I-D. And thus _every_ non-P- header will start out as a P- header. I therefore disagree with Rohan's claim that it is 99% a non-problem. Bill Marshall wtm@research.att.com -----original message----- Date: Sat, 23 Mar 2002 17:21:21 -0600 From: Henning Schulzrinne To: Ben Campbell Cc: sip@ietf.org, Rohan Mahy Subject: Re: [Sip] Options for P- header standardization To add to this, it seems experience teaches us that the standardization status of a draft is subject to changes very late in the game, for any number of reasons. A non-exhaustive list includes: - IPR issues that pop up at any point and then argue for "demotion" to informational; as participants of this working group know, this isn't exactly a theoretical case. - IESG concerns that only appear after last call; - external reference issues ("organization X needs a standards-track RFC for a normative reference"). Depending on the direction, suddenly a P- header needs to drop the prefix or a non-P header needs to acquire it, leading to the duplication of headers or breaking of existing implementations. SIP itself saw a fair bit of implementation before the RFC came out, with the first bake-off tests with dozens of implementations being done weeks after the RFC. Unless we want to switch to an ITU model ("thou must not implement before the spec has been stenciled on parchment"), we need to provide some good-faith protection to implementors. Obviously, there can be no guarantee of backwards-compatibility if the reason has sufficient technical merit, but I find it hard to tell an implementor with a straight face that their shipping product is broken because of some unpredictable external forces, not because of any technical flaws. Unless we are becoming completely legalistic, expediency and good-faith protection will lead us to make exceptions, which then further erodes any significance of the designator. To add another reason why duplicate headers are bad: Logging becomes a pain. The logging logic now needs to know that it should log only one of the header instances, as otherwise any searching or sorting gets even more painful. Yet another one: sip-cgi, SIP servlet and CPL logic gets bloated, since I now need to check two header names in all comparisons. People will forget to do this, and suddenly scripts go erratic in subtle ways. Also, as soon as you have two headers with the same function but different names, any headers where proxies add instances (as in Via) require elaborate logic and become extremely brittle. Let's say a proxy only knows about the non-P header and adds an instance to it. It doesn't know about the P-header. (Doesn't really matter which way the proxy tends.) Suddenly, the UAS gets two headers that are supposed to be the same, but aren't. Duh. Another brittleness: Headers that are included in both the S/MIME-protected body and the outer header. Again, elaborate logic is needed to reconcile the P-/non-P headers. I suspect that there any number of other things that could break. People have suggested getting rid of the compact headers; all of the reasons offered apply in spades here. Indeed, if we allow headers to acquire or drop prefixes, most of the same arguments would lead one to think that adding compact forms later on would be a good idea. I grant that any of these problems identified can be fixed individually, at significant spec bloat. (Plus, it seems a little late to do this now that the RFC has shipped. Thus, suddenly 'bis' implementations are all broken.) This, I think, is an example of "aliasing", which is always a rather dangerous concept, starting from Fortran COMMONs in the 1960s to pointer aliasing in C/C++. Thus, I suggest that people proposing duplicating header fields have a fairly high standard of proof that they need to meet as to why there is no other solution and what the benefits might be. Henning Ben Campbell wrote: > > I have to agree with Henning. > > All the options that Rohan listed result in one of three things: > > 1) You can't really know that a header is non-standard unless you look up > the RFC/IANA registration. > 2) All implementations must support 2 possible header names for the same > thing > 3) No backwards compatibility to pre-standard implementations. > > Of these 3, the least damaging appears to be result #1. > > This is identical to the result of not bothering with the "p" prefix in the > first place. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 09:37:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11902 for ; Mon, 25 Mar 2002 09:37:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13493 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 09:37:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08276; Mon, 25 Mar 2002 09:15:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08231 for ; Mon, 25 Mar 2002 09:15:55 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11181 for ; Mon, 25 Mar 2002 09:15:52 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2PEFrl26078; Mon, 25 Mar 2002 08:15:53 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PEFqr14054; Mon, 25 Mar 2002 08:15:52 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA13709; Mon, 25 Mar 2002 08:15:51 -0600 (CST) Message-ID: <3C9F31DD.6E981D24@lmf.ericsson.se> Date: Mon, 25 Mar 2002 16:19:09 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'sip@ietf.org '" References: <8C92E23A3E87FB479988285F9E22BE46C399B9@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > I stated that "e2e reservations do not 'necessarily' ensure end to end QoS". Yes, we have been speaking about this for a while already. What manyfolks provides you is a hook between the application and the reservation protocol. When the reservation protocol is an e2e protocol (e.g., RSVP), you need to know when the send and the recv directions are ready in order to resume session establishment. This framework assumes that when the reservation protocol says that the send direction is ready, it is true. What you are saying is that the framework should say: "when the other end tells you that the send direction is ready, don't believe it, because it is not necessarily so. e2e reservation protocols do not work, so the other end is missinformed when he states that resources in the send directions are reserved." What I am trying to say is that the fact that e2e reservation protocols may not ensure e2e QoS is not a problem of the framework but a problem of the reservation protocol itself. The manyfolks framework should not describe whether reservation protocols work or not. It only transports the information the resource reservation protocols provides (that is, the status of resource reservation as seen by the resource reservation protocol). Take into account that if you want preconditions to work, you have to trust the reservation protocol. If you receive a messages saying: "I have reserved resources in the send direction", and you do not trust it, preconditions are useless. Since you could not be sure whether or not the preconditions were met, you would never resume sessione establishment. > In the manyfolks draft and in your follow-up to my wording issue you state > that segmented does not ensure QoS whilst e2e protocol does. Thereby you are > stating that segmented is somehow less able to satisfy preconditions and > hence, according to my concern, is considered worse in this specific regard. > If you use e2e status type, there is something in the SDP that tells you that there are e2e resources. As I said before, manyfolks assumes that you trusts your reservation protocol. when you use local/remote tags, there is nothing in the SDP that tells you anything about the backbone. Therefore, there may be resources or there may not be resources. The fact is that with the information in the SDP you cannot tell. Let me give you an example. I can say that the use of segmented preconditions do not ensure that today is a sunny day. You may claim that you are using segmented preconditions and that the day is very sunny, but the fact is that the information in the SDP does not tell you anything about the weather nor about resources in the backbone. Therefore, when you use the segmented status type, there may be resources in the backbone, or there may not be resources in the backbone. And the same way, it may be a sunny day, or it may rain. > The draft should leave the subject, and relative merits, of how operators > provide and ensure QoS to them. They can use pre-provisioned, segmented, e2e > and combinations, with suitable dimensioning risks (call blocking v call > degradation probabilities) for the commercial model. the draft does not give any advise about commercial models. As I already stated, there are organizations using both status types. Best regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 09:38:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11927 for ; Mon, 25 Mar 2002 09:38:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13619 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 09:38:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09576; Mon, 25 Mar 2002 09:21:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09513 for ; Mon, 25 Mar 2002 09:21:33 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11365 for ; Mon, 25 Mar 2002 09:21:30 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2PELWl28787; Mon, 25 Mar 2002 08:21:32 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PELVr15853; Mon, 25 Mar 2002 08:21:31 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA14165; Mon, 25 Mar 2002 08:21:30 -0600 (CST) Message-ID: <3C9F3330.C1F3401F@lmf.ericsson.se> Date: Mon, 25 Mar 2002 16:24:48 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'sip@ietf.org '" Subject: Re: [Sip] Re: Manyfolks Clarifications References: <8C92E23A3E87FB479988285F9E22BE46C399BA@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > Then what should a DCS UA use to a 3G UA and visaversa ? 3G clients will use the segmented status type to speak between them. When a call goes outside the IMS, if 3G terminals support any e2e protocol they can use mandatory e2e. If they don't, they simply cannot reserve network resources towards the other end. > And what should DCS and 3G use to an existing Internet host (say connected > to Worldcom), and visaversa ? Same as above. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 09:43:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12124 for ; Mon, 25 Mar 2002 09:43:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15028 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 09:43:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10764; Mon, 25 Mar 2002 09:26:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10704 for ; Mon, 25 Mar 2002 09:26:27 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11463 for ; Mon, 25 Mar 2002 09:26:24 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2PEPtO22431 for ; Mon, 25 Mar 2002 09:25:55 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Mar 2002 14:25:54 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E95A@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] Options for P- header standardization Date: Mon, 25 Mar 2002 14:25:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org All this discussion seems to be trying to identify that some semantic meaning should be attached to P-headers within the implementation, rather than just in the status of the header within the IETF. For Rohan's original post, his statement about this most candidates for P-headers always staying as P-headers applies once they reach RFC status. There are 3 meanings of P - preliminary, private and proprietary. We should not regard "preliminary" as being "fast track" for a more generic solution. We should only regard "preliminary" as a quick solution where the requirements for a full generic solution are not yet known, and the "preliminary" solution will therefore not be one and the same as the full generic solution. It is possible that in all these cases, the mechanism specified is later realised to be so useful that it becomes defacto the generic solution. However in most cases, this is not meant to happen. If it does happen, and the mechanism is essentially unchanged, i.e. the processing of the header is identical, then I believe it should remain a P-header. For the recognition of the validity of the original mechanism to occur, then there will already be implementations out there, and there is no point in arguing for a name change merely for the sake of keeping the documentation pretty. Therefore in this case I support (1) in Rohan's original posting. If the mechanism does change, then obviously a new header name is required as the semantics associated with the processing of the header are different. Keith -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: 25 March 2002 13:09 To: sip@ietf.org Cc: hgs@cs.columbia.edu; bcampbell@dynamicsoft.com; rohan@cisco.com Subject: Re: [Sip] Options for P- header standardization For the sake of interoperability, it seems that every receiver must immediately strip the "P-" prefix from every header received in a message before processing it. Senders then use "best available information" at the time of shipping to decide whether to convert "Foo" to "P-Foo". (General rule: Be strict in what you send, generous in what you accept). This is the only way of solving the messy problem of keeping the P-Via headers combined and in order with the Via headers. So if those two rules are followed, (1) we get interoperability, and (2) the P- prefix is meaningless. I think these two go together. Changing the header name midway through the standardization process is a deliberate attempt to break early implementations. This tactic is seen in other standards bodies; hopefully IETF won't go that route. Since the whole point of the IANA registration is to avoid name clashes, waiting until publication as an RFC is way too late. The registration needs to happen with the individual's -00 I-D. And thus _every_ non-P- header will start out as a P- header. I therefore disagree with Rohan's claim that it is 99% a non-problem. Bill Marshall wtm@research.att.com -----original message----- Date: Sat, 23 Mar 2002 17:21:21 -0600 From: Henning Schulzrinne To: Ben Campbell Cc: sip@ietf.org, Rohan Mahy Subject: Re: [Sip] Options for P- header standardization To add to this, it seems experience teaches us that the standardization status of a draft is subject to changes very late in the game, for any number of reasons. A non-exhaustive list includes: - IPR issues that pop up at any point and then argue for "demotion" to informational; as participants of this working group know, this isn't exactly a theoretical case. - IESG concerns that only appear after last call; - external reference issues ("organization X needs a standards-track RFC for a normative reference"). Depending on the direction, suddenly a P- header needs to drop the prefix or a non-P header needs to acquire it, leading to the duplication of headers or breaking of existing implementations. SIP itself saw a fair bit of implementation before the RFC came out, with the first bake-off tests with dozens of implementations being done weeks after the RFC. Unless we want to switch to an ITU model ("thou must not implement before the spec has been stenciled on parchment"), we need to provide some good-faith protection to implementors. Obviously, there can be no guarantee of backwards-compatibility if the reason has sufficient technical merit, but I find it hard to tell an implementor with a straight face that their shipping product is broken because of some unpredictable external forces, not because of any technical flaws. Unless we are becoming completely legalistic, expediency and good-faith protection will lead us to make exceptions, which then further erodes any significance of the designator. To add another reason why duplicate headers are bad: Logging becomes a pain. The logging logic now needs to know that it should log only one of the header instances, as otherwise any searching or sorting gets even more painful. Yet another one: sip-cgi, SIP servlet and CPL logic gets bloated, since I now need to check two header names in all comparisons. People will forget to do this, and suddenly scripts go erratic in subtle ways. Also, as soon as you have two headers with the same function but different names, any headers where proxies add instances (as in Via) require elaborate logic and become extremely brittle. Let's say a proxy only knows about the non-P header and adds an instance to it. It doesn't know about the P-header. (Doesn't really matter which way the proxy tends.) Suddenly, the UAS gets two headers that are supposed to be the same, but aren't. Duh. Another brittleness: Headers that are included in both the S/MIME-protected body and the outer header. Again, elaborate logic is needed to reconcile the P-/non-P headers. I suspect that there any number of other things that could break. People have suggested getting rid of the compact headers; all of the reasons offered apply in spades here. Indeed, if we allow headers to acquire or drop prefixes, most of the same arguments would lead one to think that adding compact forms later on would be a good idea. I grant that any of these problems identified can be fixed individually, at significant spec bloat. (Plus, it seems a little late to do this now that the RFC has shipped. Thus, suddenly 'bis' implementations are all broken.) This, I think, is an example of "aliasing", which is always a rather dangerous concept, starting from Fortran COMMONs in the 1960s to pointer aliasing in C/C++. Thus, I suggest that people proposing duplicating header fields have a fairly high standard of proof that they need to meet as to why there is no other solution and what the benefits might be. Henning Ben Campbell wrote: > > I have to agree with Henning. > > All the options that Rohan listed result in one of three things: > > 1) You can't really know that a header is non-standard unless you look up > the RFC/IANA registration. > 2) All implementations must support 2 possible header names for the same > thing > 3) No backwards compatibility to pre-standard implementations. > > Of these 3, the least damaging appears to be result #1. > > This is identical to the result of not bothering with the "p" prefix in the > first place. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 09:49:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12300 for ; Mon, 25 Mar 2002 09:49:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA16293 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 09:49:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10696; Mon, 25 Mar 2002 09:26:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10650 for ; Mon, 25 Mar 2002 09:26:19 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11460 for ; Mon, 25 Mar 2002 09:26:16 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PEOZS21900; Mon, 25 Mar 2002 15:24:35 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PENvX17780; Mon, 25 Mar 2002 14:23:57 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 14:24:41 -0000 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , sip@ietf.org Cc: Rohan Mahy , jo@ipdialog.com, brian.rosen@marconi.com, wtm@research.att.com, Flemming Andreasen Subject: RE: [Sip] WGLC for Informational Draft on Media Authorization Date: Mon, 25 Mar 2002 14:24:37 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D408.CB1169EC" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D408.CB1169EC Content-Type: text/plain; charset="iso-8859-1" All, A very late but very small, and perhaps important, comment: the header carries a hex string which contains a Policy Element as defined in RFC2750, including length and P-Type. Should it be able to carry more than one Policy Element ? RSVP allows you to include more than one, and since the Policy Elements can be of different types, the flexibility to include more than one could be of value. Sinec the token in this header is just a hex string, including length and type bytes, then the syntax can remain the same, and the procedure at the UAs (copy the data into the appropriate place in the RSVP POLICY-DATA object) remains the same. Regards...Mark > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 10 March 2002 22:09 > To: sip@ietf.org > Cc: Rohan Mahy; jo@ipdialog.com; brian.rosen@marconi.com; > wtm@research.att.com; Flemming Andreasen > Subject: [Sip] WGLC for Informational Draft on Media Authorization > > > We'd like to open discussion for a working group lst call on: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-call-auth-04.txt > > Please note that this is not a standards-track draft. It > defines a p-class > header used for interworking with a restricted set of QoS > policy managers > potentially used in some cable and wirless networks, It is > also part of the > "Bundle 2" set deemed critical by 3GPP. > > We plan to conclude WGLC on or about 25 March 2002 and > advance to IETF last > call as soon as possible thereafter. > > -- > Dean Willis > SIP WG co-chair. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1D408.CB1169EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] WGLC for Informational Draft on Media = Authorization

All,

A very late but very small, and perhaps important, = comment: the header carries a hex string which contains a Policy = Element as defined in RFC2750, including length and P-Type. Should it = be able to carry more than one Policy Element ? RSVP allows you to = include more than one, and since the Policy Elements can be of = different types, the flexibility to include more than one could be of = value.

Sinec the token in this header is just a hex string, = including length and type bytes, then the syntax can remain the same, = and the procedure at the UAs (copy the data into the appropriate place = in the RSVP POLICY-DATA object) remains the same.

Regards...Mark



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.c= om]
> Sent: 10 March 2002 22:09
> To: sip@ietf.org
> Cc: Rohan Mahy; jo@ipdialog.com; = brian.rosen@marconi.com;
> wtm@research.att.com; Flemming Andreasen
> Subject: [Sip] WGLC for Informational Draft on = Media Authorization
>
>
> We'd like to open discussion for a working = group lst call on:
>
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-c= all-auth-04.txt
>
> Please note that this is not a standards-track = draft. It
> defines a p-class
> header used for interworking with a restricted = set of QoS
> policy managers
> potentially used in some cable and wirless = networks, It is
> also part of the
> "Bundle 2" set deemed critical by = 3GPP.
>
> We plan to conclude WGLC on or about 25 March = 2002 and
> advance to IETF last
> call as soon as possible thereafter.
>
> --
> Dean Willis
> SIP WG co-chair.
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1D408.CB1169EC-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 09:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12543 for ; Mon, 25 Mar 2002 09:55:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17698 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 09:55:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12742; Mon, 25 Mar 2002 09:34:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12701 for ; Mon, 25 Mar 2002 09:34:44 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11756 for ; Mon, 25 Mar 2002 09:34:40 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g2PEYar04558; Mon, 25 Mar 2002 09:34:37 -0500 Message-Id: <200203251434.g2PEYar04558@minotaur.nge.isi.edu> To: Rohan Mahy cc: sip@ietf.org Reply-To: mankin@isi.edu Subject: Re: [Sip] Options for P- header standardization In-reply-to: Your message of Sat, 23 Mar 2002 12:55:29 -0800. Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Mon, 25 Mar 2002 09:34:36 -0500 From: Allison Mankin Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > I'd also like to re-emphasize what I said at the microphone during the > SIP session Wednesday. We expect that 99% of P- headers will never > be standardized, so this problem is not so large as I think many have > feared. > Given the barriers to P-headers, there should be relatively few all around. People should read the list of conditions for an acceptable P-header in 6.1. The discussions that have followed Rohan's mail seem not always to have digested those, which limit the functions of a header to be proposed as P- to information provision and which require that no change in behavior or security properties results from the header in use. This process will not support designing a header like Replaces, which changes the behavior and significant properties of the dialog, and starting it as a P-header and eventually taking it to a non P- header. > Lets talk about standardization options for a "preliminary" header: P-Foo > > 1) Just register P-Foo as a Proposed Standard This first case reduces the discussion to a bad mismatch with Section 6.1 in the draft. A header should go through the standards process as Foo if it is envisioned as a general use header extension. The P- process is not there to facilitate a trial. > 1) Defeats the point of P- headers in the first place, because the whole > point in having the P- header space is to allow folks to easily identify > which headers are not "standard". > No, the point in the "P-" being there is what Rohan says. but, the whole point of the P- space and procedures is for there to be a limited exception to the rule that SIP header extensions must meet all criteria for being standards track and make it to a standards track RFC. The circumstances in which they do not include that they carry non-behavioral altering information that is significant to a non-general community (one consortium, one deployment) or non-behavior altering information that cannot be an RFC - for instance information in law enforcement that RFC 2804 and current IESG policy would not permit on the standards track. Do not ignore the 99% statement Rohan made first. I'd bet it to be even less. Maybe we need to eliminate the string reservation feature and maybe we've erred by including "preliminary" among the glosses of P. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 10:30:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14438 for ; Mon, 25 Mar 2002 10:30:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26782 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 10:30:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22165; Mon, 25 Mar 2002 10:12:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22091 for ; Mon, 25 Mar 2002 10:12:32 -0500 (EST) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13598 for ; Mon, 25 Mar 2002 10:12:28 -0500 (EST) From: frank.derks@philips.com Received: from smtpscan-nl4.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA06051 for ; Mon, 25 Mar 2002 16:10:42 +0100 (CET) (envelope-from frank.derks@philips.com) Received: from smtpscan-nl4.philips.com(130.139.36.24) by gw-nl4.philips.com via mwrap (4.0a) id xma006044; Mon, 25 Mar 02 16:10:42 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA10955 for ; Mon, 25 Mar 2002 16:12:29 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA20738 for ; Mon, 25 Mar 2002 16:12:28 +0100 (MET) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 25 Mar 2002 16:11:08 +0100 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 25/03/2002 16:13:21, Serialize complete at 25/03/2002 16:13:21 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 005350DFC1256B87_=" Subject: [Sip] Matching responses to transactions (error in 9th draft?) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 005350DFC1256B87_= Content-Type: text/plain; charset="us-ascii" Section 17.1.3 of the 9th draft of the SIP specification states the following: "A response that matches a transaction matched by a previous response is considered to be a restransmission of that response." This statement is preceded by two "matching rules", one about a matching branch parameter in the topmost Via header and one about a matching request method in the CSeq. Suppose that multiple responses are sent as the result of an INVITE. E.g. first a 183 Trying, then a 180 Ringing and then a 200 OK. All of these would match with the request, but according to the above statement, the 180 Ringing and the 200 OK would seem to be regarded as retransmissions of the 183 Trying. This can surely not be the intention. Regards, Frank --=_alternative 005350DFC1256B87_= Content-Type: text/html; charset="us-ascii"
Section 17.1.3 of the 9th draft of the SIP specification states the following:

"A response that matches a transaction matched by a previous response is
 considered to be a restransmission of that response."

This statement is preceded by two "matching rules", one about a matching
branch parameter in the topmost Via header and one about a matching
request method in the CSeq.

Suppose that multiple responses are sent as the result of an INVITE. E.g.
first a 183 Trying, then a 180 Ringing and then a 200 OK. All of these
would match with the request, but according to the above statement, the
180 Ringing and the 200 OK would seem to be regarded as retransmissions
of the 183 Trying. This can surely not be the intention.

Regards,

Frank --=_alternative 005350DFC1256B87_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 11:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16508 for ; Mon, 25 Mar 2002 11:03:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05080 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 11:03:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02071; Mon, 25 Mar 2002 10:50:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02031 for ; Mon, 25 Mar 2002 10:50:50 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15864 for ; Mon, 25 Mar 2002 10:50:46 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2PFo3i12561; Mon, 25 Mar 2002 09:50:03 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PFo2r16801; Mon, 25 Mar 2002 09:50:02 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA22519; Mon, 25 Mar 2002 09:49:58 -0600 (CST) Message-ID: <3C9F47EC.43004BF9@lmf.ericsson.se> Date: Mon, 25 Mar 2002 17:53:16 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Dean Willis'" , sip@ietf.org, wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com Subject: Re: [Sip] WGLC for Manyfolks draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark, > Instead of 'When the current status value has the same or a better > value than the desired status value, the preconditions are considered > to be met for each stream.', I think what is meant is: > > 'When the direction-tag of the current status attribute with a given > precondition-type/status-type is equal to (or better than) the > direction-tag of the desired status attibute with the same > precondition-type/status-type, then the preconditions are considered > to be met.' Fixed. Thanks, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 11:04:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16625 for ; Mon, 25 Mar 2002 11:04:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05561 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 11:04:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00745; Mon, 25 Mar 2002 10:46:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13558 for ; Mon, 25 Mar 2002 01:05:53 -0500 (EST) Received: from ganga.smartyantra.co.in (IDENT:root@[202.142.72.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25997 for ; Mon, 25 Mar 2002 01:05:48 -0500 (EST) Received: from godavari ([192.168.1.47]) by ganga.smartyantra.co.in (8.11.0/8.11.0) with SMTP id g2P6EmD18671; Mon, 25 Mar 2002 11:44:50 +0530 Message-ID: <004501c1d3c4$7a5ab420$2f01a8c0@godavari> From: "Nagaraj" To: , Date: Mon, 25 Mar 2002 11:45:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C1D3F2.91E16A20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Sip] Timeout condition in hold state Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C1D3F2.91E16A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 Is there any provision in SIP to take care of the timeout in holding = condition ? Consider a situation:=20 ua-A establishes a SIP session with ua-B. After some time ua-B requests for a hold by using INVITE method. ua-A goes into "hold" state and waits for ua-B to resume.=20 If now network goes down at ua-B, and he disconnects without sending any = more SIP messages, how ua-A will come to know about it. Is there a mechanism for determining timeout value for ua-A, so that he = wont wait forever. Regards, -Nagaraj. Nagaraj. Bhat. Smart Yantra Technologies Pvt Ltd #57, 3rd Floor, HMT Layout Behind R.T. Nagar Police Station R.T. Nagar Bangalore - 560032 Phone: 91-80-3634917 / 91-80-3634918 Fax: 91-80-3631927 =20 Nagaraj_s_bhat@yahoo.com Nagaraj.bhat@vsnl.com nagaraj@smartyantra.com =20 ------=_NextPart_000_0042_01C1D3F2.91E16A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Is there any provision in SIP = to take=20 care of the timeout in holding condition ?
 
Consider a situation:
 
ua-A  establishes a SIP session = with=20 ua-B.
After some time ua-B requests for a = hold by using=20 INVITE method.
ua-A goes into "hold" state and waits = for ua-B to=20 resume.
 
If now network goes down at ua-B, and = he=20 disconnects without sending any more SIP messages,
how ua-A will come to know=20 about it.
 
Is there a mechanism for determining=20 timeout value for ua-A, so that he wont wait forever.
 
Regards,
 
-Nagaraj.
 

Nagaraj. Bhat.
Smart Yantra = Technologies Pvt=20 Ltd
#57, 3rd Floor, HMT Layout
Behind R.T. Nagar Police = Station
R.T.=20 Nagar
Bangalore - 560032
Phone: 91-80-3634917 / = 91-80-3634918
Fax:=20 91-80-3631927
 
 
Nagaraj_s_bhat@yahoo.com
= Nagaraj.bhat@vsnl.com
nagaraj@smartyantra.com
&n= bsp;
------=_NextPart_000_0042_01C1D3F2.91E16A20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 11:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17660 for ; Mon, 25 Mar 2002 11:19:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09429 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 11:19:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05059; Mon, 25 Mar 2002 11:03:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05009 for ; Mon, 25 Mar 2002 11:02:57 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16491 for ; Mon, 25 Mar 2002 11:02:52 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2PG2ol26101; Mon, 25 Mar 2002 10:02:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PG2o626010; Mon, 25 Mar 2002 10:02:50 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA23750; Mon, 25 Mar 2002 10:02:47 -0600 (CST) Message-ID: <3C9F4AEE.A39653E4@lmf.ericsson.se> Date: Mon, 25 Mar 2002 18:06:06 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juan-Carlos.Rojas@alcatel.fr CC: "'Jonathan Rosenberg '" , "Christer Holmberg (LMF)" , sip@ietf.org Subject: Re: [Sip] Re: Offer by the callee References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > I have only a last question: generally speaking, a party cannot send a new > offer, while there is still a "pending offer", that is: > - the party received an offer, and he has not sent an answer yet > - the party sent an offer, and he has not received an answer yet > > The resource reservation process associated to a given offer starts when > the offer is accepted, that is, when the answer to the offer has been > sent/received. > Therefore, a new offer can be generated by any of the parties, even if the > resource reservation process for a previously answered offer has not > finished yet. > In other words, a new offer can be sent as soon as the previous offer has > been answered (following the rules of the Offer/answer draft), but it is > not required that the current-status reach the desired-status. > Do you agree on that ? Yes, your understanding is correct. As a matter of fact, you will typically send offers containing a confirmation while the other party is still performing resource reservation. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 11:23:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17816 for ; Mon, 25 Mar 2002 11:23:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10284 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 11:23:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06349; Mon, 25 Mar 2002 11:06:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06317 for ; Mon, 25 Mar 2002 11:06:53 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16854 for ; Mon, 25 Mar 2002 11:06:50 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id LAA18157; Mon, 25 Mar 2002 11:05:12 -0500 (EST) Subject: Re: [Sip] Timeout condition in hold state To: "Nagaraj" Cc: , Date: Mon, 25 Mar 2002 11:05:10 -0500 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 03/25/2002 11:05:12 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA06318 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit This appears to be more concerned with specific call processing issues and policies than with SIP. It should be handled outside of SIP. A similar concern could be raised about long duration calls. A stateful proxy will reserve resources for all calls. If no activity is seen on a call for a significant period of time, what should be done? Currently in the PSTN in North America, calls are terminated in the network if they have been up for 48 hours to preserve resources. I do not see this being as SIP issue as well although it will need to be implemented on SIP-enable systems. "Nagaraj" @ietf.org on 03/25/2002 01:15:32 AM Sent by: sip-admin@ietf.org To: , cc: Subject: [Sip] Timeout condition in hold state Hi all, Is there any쟰rovision쟧n SIP to take care of the timeout in holding condition�? Consider a situation: ua-A� establishes a SIP session with ua-B. After some time ua-B requests for a hold by using INVITE method. ua-A goes into "hold" state and waits for ua-B to resume. If now network goes down at ua-B, and he disconnects without sending any more SIP messages, how ua-A will come to know about쟧t. Is there a mechanism for determining timeout쟶alue for ua-A, so that he wont wait forever. Regards, -Nagaraj. Nagaraj. Bhat. Smart Yantra Technologies Pvt Ltd #57, 3rd Floor, HMT Layout Behind R.T. Nagar Police Station R.T. Nagar Bangalore - 560032 Phone: 91-80-3634917 / 91-80-3634918 Fax: 91-80-3631927 Nagaraj_s_bhat@yahoo.com Nagaraj.bhat@vsnl.com nagaraj@smartyantra.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 daemon@optimus.ietf.org Mon Mar 25 12:43:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22127 for ; Mon, 25 Mar 2002 12:43:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00694 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 12:43:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21180; Mon, 25 Mar 2002 12:05:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21130 for ; Mon, 25 Mar 2002 12:05:35 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20267 for ; Mon, 25 Mar 2002 12:05:31 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2PH50i21647; Mon, 25 Mar 2002 11:05:00 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PH4xJ16215; Mon, 25 Mar 2002 11:04:59 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA29661; Mon, 25 Mar 2002 11:04:57 -0600 (CST) Message-ID: <3C9F597F.4ED220EC@lmf.ericsson.se> Date: Mon, 25 Mar 2002 19:08:15 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Chen, Xin (Xin)" CC: Juan-Carlos.Rojas@alcatel.fr, sip@ietf.org Subject: Re: [Sip] Codecs selection & QoS reservation--Manyfolks References: <475FF955A05DD411980D00508B6D5FB004992CE8@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, As Juan Carlos pointed out, you always perform reservations for the highest bandwidth codec (if bandwidth is the metric you use for QoS). Regards, Gonzalo "Chen, Xin (Xin)" wrote: > > Hi Juan, > > Unless we have a globle QoS mapping standards or both ends use same QoS > reservation protocol, I double both ends will get the same answer which > needs more QoS. > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > -----Original Message----- > From: Juan-Carlos.Rojas@alcatel.fr [mailto:Juan-Carlos.Rojas@alcatel.fr] > Sent: 21 March 2002 17:25 > To: Chen, Xin (Xin) > Cc: sip@ietf.org > Subject: Re: [Sip] Codecs selection & QoS reservation--Manyfolks > > Hi, > > Indeed, parties can use any of those negotiated codecs in the list without > session re-negotiation. > Therefore, should both end-points take into account the highest bandwidth > requirements for resource reservation ? > > Best regards > Juan Carlos > > "Chen, Xin (Xin)" @ietf.org on 21/03/2002 17:52:59 > > Sent by: sip-admin@ietf.org > > To: sip@ietf.org > cc: > Subject: [Sip] Codecs selection & QoS reservation--Manyfolks > > Hi, > > There a case in my mind: > > A offers one m= line with 5 codecs also with precondition either local or > e2e, B answers with 3 of the 5, and according to manyfolks, both A and B > starts to QoS reservation either local or e2e. > > Since there are 3 codecs can be used for communication, is there a problem > that A and B reserve the QoS based on different codecs, let's assume that > the codec A used for QoS reservation requires higher QoS that B used, will > there be a problem for the session? > > This is like the one-of-N codecs problem mentioned in unify draft. > > Shall we mandate that A and B always use the first codec for QoS > reservation > since the first one is the prefered one? > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Mon Mar 25 13:23:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24242 for ; Mon, 25 Mar 2002 13:23:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10382 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 13:23:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04759; Mon, 25 Mar 2002 12:58:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04620 for ; Mon, 25 Mar 2002 12:58:47 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22856 for ; Mon, 25 Mar 2002 12:58:44 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2PHwfl04055; Mon, 25 Mar 2002 11:58:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PHwer06854; Mon, 25 Mar 2002 11:58:40 -0600 (CST) Received: from lmf.ericsson.se (rmt160125.am.ericsson.se [138.85.160.125]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05233; Mon, 25 Mar 2002 11:58:37 -0600 (CST) Message-ID: <3C9F6613.FF26B87F@lmf.ericsson.se> Date: Mon, 25 Mar 2002 20:01:55 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'David R. Oran '" , "'sip@ietf.org '" Subject: Re: [Sip] Manyfolks: Unified local/remote model References: <8C92E23A3E87FB479988285F9E22BE46C372CF@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, The problem with your suggestion is that the offerer specifies what he will do, not what he wants. For instance, if the offerer says "remote", it means (in your model) that he will perform resource reservations in the answerer's access network. But what we really want to say is: I want QoS in your access network. Do whatever to ensure that. You claim that in manyfolks-05 the offerer chooses the status type (segmented or e2e) and that the answerer cannot change it. This is not a problem. If I ask for mandatory e2e, I do not want the answerer to change it to segmented. However, if I ask for segmented and I support e2e, it will be acceptable for me that the status type is changed from segmented to e2e. Manyfolks-05 already covers this, since the offerer will include mandatory local/remote and optional e2e (to indicate support for the e2e status type). The answerer can upgrade the e2e line to mandatory, and assume that the local/remote preconditions are met once the e2e preconditions are met. Alan, the current manyfolks mechanism is what DCS and 3GPP want. Everything they need in their call flows is covered by manyfolks-05. Which is the scenario you have in mind that we do not currently cover? Thanks, Gonzalo Alan O'Neill wrote: > > Dave, > > Here is one way to view local/remote and e2e which I believe better supports > inter-domain preconditions. This is through the removal of the two distinct > status types because they are a barrier to efficient offer/answer > negotiation between heterogeneous domains, specifically because you need to > use a new offer if a UA starts with the wrong status type. It also requires > two sets of processing rules which is unnecessarily complex and avoids the > e2e v segmented beauty contest..It certainly is not a design though just a > way to represent the ideas. > > As before, all preconditions should be assumed to be a request for end to > end resources in the direction indicated by the direction tag. As before all > preconditions requests are e2e in nature but the QoS mechanisms supporting > these may not be. The current status reflects where we are compared to the > desired status. Offerer offers, the answerer answers, and Update is used > where necessary for confirmation. Precondition directions as always are wrt > to the SDP sender > > But lets instead use nill, local, remote and localremote where localremote > implies the availability of an end to end QoS protocol. From the view of two > UAs, localremote is as much as we can negotiate as neither UA knows anything > about the core in reality, even with an end to end protocol. > > The offerer follows manyfolks-05 and selects between nill, local, remote, > localremote as to its desired status towards meeting preconditions in the > specific direction. The answerer can then select from the offered desired > status and can specifically choose a subset or move from segmented to e2e > models. This is achieved by both the desired status and strength being > negotiable with the answerer responding to the offerer. > > Lets assume for direction caller(offerer) to callee(answerer) we have an > optional precondition. > > caller sends a=des:qos optional X send > callee sends a=des:qos optional Y recv > > Note that both ends keep there own view of what they have to do to meet > precondition so offerer/answerer des lines are different in each direction. > For below note RSVP is used as one example of a protocol giving feedback).. > > Actual Actual > Offered X Answered Y Meaning > nill nill Nothing will be booked > local Answerer happy to book its > end > remote Answerer books other end using RSVP > but local RSVP not supported. > localremote eg e2e via e2e signalling eg > RSVP attempted by answerer for both ends > local nill Answerer won't book > anything, offerer can > local e2e via segmented model > remote Answerer will book resources using > say RSVP > localremote e2e via e2e signalling eg > RSVP attempted by answerer for both ends > remote nill Anwerer won't book anything,left to > offerer > local Answerer happy to book its > end > remote Inverse segmented - each doing other > ends QoS (maybe for policy reasons ?) > localremote e2e via e2e signalling eg > RSVP attempted by answerer for both ends > localremote nill Happy for offerer to do e2e > via e2e signaling > local Switch to segmented model > with each doing local > remote switch to inverse segmented model > (each doing the others end) > localremote answerer over-rules and > wishes to book > > Of course the answerer can also respond with 'none' strength to cancel the > offered precondition, or stengthen it to 'mandatory' to tighten the > requirement for the desired status for the offerer. The offerers SDP should > now reflect the change requested by the answerer and no additional desired > status negotiation is possible through updates, which only affect current > status (I think that is optimal) > > Now at this point both ends know what needs to be done, and by whom..If > offerer is not happy it can re-offer or end the call-leg. Otherwise we move > to the current-status aspects... > > The current-status of the offerer will limit the flexibility open to the > answerer, in its response to the offered desired status, by including > information indicating that the offerer is starting the booking of, or > announcing the availability of, resources matching the offerers desired > status. The answerer should not modify the desired status by contravening > the current status of the offerer. > > The current status and each end then moves towards the desired status. The > callee should not alert until the preconditions are met and the caller > should send an Update when it learns additional information not known to the > callee about the current status via changes in its local booking and its > booking of remote resources, whether as part of a segmented, inverse > segmented or end to end signalling model. > > I hope I having missed anything and that the addition of an integrated > local, remote, localremote model eliminates two competing approaches and the > risk of the offerer starting with the wrong model. I hope I haven't missed > anything but this is kin of where I was going with my analysis... > > Alan. > > ---------------------------------------------------------------- > Notice Regarding Intellectual Property Rights > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > protection on some or all of the technical information submitted by its > employees in connection with the IETF's standards process. If part(s) of a > submission by Flarion is (are) included in a standard and Flarion owns > patent(s) and/or pending patent application(s) that are essential to > implementation of such included part(s) in said standard, Flarion is > prepared to grant a license on fair, reasonable, reciprocal (license back) > and non-discriminatory terms on such included part(s). > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Mon Mar 25 13:32:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24858 for ; Mon, 25 Mar 2002 13:32:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12698 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 13:32:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06756; Mon, 25 Mar 2002 13:07:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06702 for ; Mon, 25 Mar 2002 13:07:07 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23230 for ; Mon, 25 Mar 2002 13:07:04 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Mar 2002 10:06:35 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Mar 2002 10:06:35 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 25 Mar 2002 10:06:31 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Mar 2002 10:06:34 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 25 Mar 2002 10:03:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Manyfolks: Unified local/remote model Date: Mon, 25 Mar 2002 10:03:20 -0800 Message-ID: Thread-Topic: [Sip] Manyfolks: Unified local/remote model thread-index: AcHUJpOY5kTvA95KRy6VJQyeze9BtAAAHNUQ From: "Christian Huitema" To: "Gonzalo Camarillo" , "Alan O'Neill" Cc: "David R. Oran " , X-OriginalArrivalTime: 25 Mar 2002 18:03:19.0271 (UTC) FILETIME=[58436770:01C1D427] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA06703 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > The problem with your suggestion is that the offerer specifies what he > will do, not what he wants. For instance, if the offerer says "remote", > it means (in your model) that he will perform resource reservations in > the answerer's access network. But what we really want to say is: I want > QoS in your access network. Do whatever to ensure that. The problem with QoS signaling is that it may or may not reflect any change of state in the network. The only way to be sure that there is available bandwidth is to perform a continuity test -- and even that will only give us an "instant snapshot", rather than a guarantee that the bw will still be available in the future. In fact, the continuity test would be very useful in many scenarios, regardless of QoS. In today's world of firewalls and NATs, I can see many cases in which two parties successfully negotiate codecs and other SDP parameters, and then find out that they cannot actually communicate. The same considerations that drove the DCS effort apply: we should perform an RTP continuity test before ringing the called party... -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 15:32:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01943 for ; Mon, 25 Mar 2002 15:32:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13352 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 15:32:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10659; Mon, 25 Mar 2002 15:20:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10624 for ; Mon, 25 Mar 2002 15:20:55 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01275 for ; Mon, 25 Mar 2002 15:20:53 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2PKKGK18138; Mon, 25 Mar 2002 12:20:16 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA00735; Mon, 25 Mar 2002 12:20:15 -0800 (PST) Message-ID: <3C9F8675.6626676A@cisco.com> Date: Mon, 25 Mar 2002 15:20:05 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruppelt Christian CC: sip@ietf.org Subject: Re: AW: [Sip] question on privacy 04 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ruppelt Christian wrote: > The text in 7.1 Untrusted UAC Behavior > says: > ... and the UAC wants to control the privacy > for any Remote-Party-ID ... by a downstream proxy. > Each of these RPID-privacy headers ... > to maintain privacy of the "addr-spec" > > My question is: where does this "addr-spec" come from? Most likely, the proxy has access to a database that can map from the authenticated identity to the actual addr-spec to use for the Remote-Party-Id. > The proxy needs it to add a corresponding Remote-Party-ID. > Could this be outside the scope of the draft? Yes. The draft simply assumes that the identity has been determined and the proxy inserts a corresponding addr-spec in the Remote-Party-Id. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 16:03:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03450 for ; Mon, 25 Mar 2002 16:03:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20746 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 16:03:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15229; Mon, 25 Mar 2002 15:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15194 for ; Mon, 25 Mar 2002 15:39:42 -0500 (EST) Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02305 for ; Mon, 25 Mar 2002 15:39:40 -0500 (EST) Received: from VladicaStanisic@netscape.net by imo-r05.mx.aol.com (mail_out_v32.5.) id l.13b.1816286 (16228) for ; Mon, 25 Mar 2002 15:39:08 -0500 (EST) Received: from netscape.com (mow-m01.webmail.aol.com [64.12.184.129]) by air-in02.mx.aol.com (v84.12) with ESMTP id MAILININ24-0325153908; Mon, 25 Mar 2002 15:39:08 -0500 Date: Mon, 25 Mar 2002 15:39:08 -0500 From: VladicaStanisic@netscape.net (Vladica Stanisic) To: sip@ietf.org Message-ID: <0604C8AC.70AB6326.DAA535D6@netscape.net> X-Mailer: Atlas Mailer 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: [Sip] header fields' sizes in SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I am a student working on SIP designing a control memory. Header fields' sizes in SIP are not defined since SIP is text based protocol. Can anybody give me guidelines about sizes of mandatory header fields Allow Call-ID Contact Content-Length Content-Type From Proxy-Authenticate Supported To Unsupported Via WWW-Authenticate Thanks -- Vladica Stanisic Research Assistant North Carolna State University e-mail:vjstanis@eos.ncsu.edu __________________________________________________________________ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.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 daemon@optimus.ietf.org Mon Mar 25 16:52:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05045 for ; Mon, 25 Mar 2002 16:52:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA03070 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 16:52:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24523; Mon, 25 Mar 2002 16:18:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24463 for ; Mon, 25 Mar 2002 16:18:36 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03892 for ; Mon, 25 Mar 2002 16:18:31 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2PLHoi02129; Mon, 25 Mar 2002 15:17:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2PLHnv18541; Mon, 25 Mar 2002 15:17:49 -0600 (CST) Received: from lmf.ericsson.se (rmt160208.am.ericsson.se [138.85.160.208]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23277; Mon, 25 Mar 2002 15:17:46 -0600 (CST) Message-ID: <3C9F94C0.F2341EBA@lmf.ericsson.se> Date: Mon, 25 Mar 2002 23:21:04 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, wtm@research.att.com, Gonzalo Camarillo , jo@ipdialog.com, Rohan Mahy , brian.rosen@marconi.com References: <00ca01c1c880$8c8d8ae0$133fed0c@C1893415A> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: WGLC for Manyfolks draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have just submitted a new version of the draft that includes all the comments received during the WGLC. Until it appears in the archives, you can fetch it from: http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-06.txt http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-06.pdf Regards, Gonzalo Dean Willis wrote: > > We'd like to open discussion for working group last call on: > > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-manyfolks-resource-05.t > xt > > This is part of the "Bundle 2" group needed by 3GPP. > > The working group last call discussion period will close immediately after > IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as > possible thereafter. > > -- > Dean Willis > SIP WG Co-Chair -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Mon Mar 25 17:13:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05880 for ; Mon, 25 Mar 2002 17:13:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08266 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 17:13:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02191; Mon, 25 Mar 2002 16:49:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02168 for ; Mon, 25 Mar 2002 16:49:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04940 for ; Mon, 25 Mar 2002 16:49:10 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2PLmgY18011 for ; Mon, 25 Mar 2002 13:48:42 -0800 (PST) Received: from soneilw2k (dhcp-128-107-141-104.cisco.com [128.107.141.104]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ACK64665; Mon, 25 Mar 2002 13:48:53 -0800 (PST) From: "Sean O'Neil" To: Date: Mon, 25 Mar 2002 13:48:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Content-Transfer-Encoding: 7bit Subject: [Sip] Is it ever correct to authenticate a 302? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Is it every appropriate to authenticate a 302 with a 401 or 407? Is/should a 302 be a request, a response or both? Example. Invite goes through a proxy to an endpoint which returns a 302 to the proxy with a PSTN contact. The service provider would like to bill the client forwarding the 302 for the next call leg out through the pstn, but needs to authenticate the sender of the 302 response to ensure that he has ability to bill for next leg of call. How can the proxy enforce that the initiator of the 302 have an address of record in its registry database? Thanks Sean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 17:39:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06589 for ; Mon, 25 Mar 2002 17:39:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14715 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 17:39:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08195; Mon, 25 Mar 2002 17:13:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08162 for ; Mon, 25 Mar 2002 17:13:15 -0500 (EST) Received: from uni03mr.unity.ncsu.edu (uni03mr.unity.ncsu.edu [152.1.1.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05861 for ; Mon, 25 Mar 2002 17:13:12 -0500 (EST) Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id RAA10714; Mon, 25 Mar 2002 17:13:13 -0500 (EST) Message-ID: <147d01c1d44a$4207cb40$743c0198@ecew2k.ncsu.edu> From: "Prabhas Sinha" To: "Vladica Stanisic" , References: <0604C8AC.70AB6326.DAA535D6@netscape.net> Subject: Re: [Sip] header fields' sizes in SIP Date: Mon, 25 Mar 2002 17:13:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think this information is available in the RFC , I had read it long time back but I'll put it here for you: To: (50 bytes for name/address-space) + (8 bytes for tag) = 58 bytes From: (50 bytes for name/address-space) + (8 bytes for tag) = 58 bytes Content Length: 12 bytes Call-ID: 50 bytes Content Encoding: 50 bytes Content Type: 50 bytes CSeq: 12 bytes Via: 75 bytes If there is some changes to it then somebody please correct me. Moreover, please send your questions to sip-implementors@cs.columbia.edu from now onwards. Thanks, Prabhas ----- Original Message ----- From: "Vladica Stanisic" To: Sent: Monday, March 25, 2002 3:39 PM Subject: [Sip] header fields' sizes in SIP > I am a student working on SIP designing a control memory. > Header fields' sizes in SIP are not defined since SIP is text based protocol. > Can anybody give me guidelines about sizes of mandatory header fields > > Allow > Call-ID > Contact > Content-Length > Content-Type > From > Proxy-Authenticate > Supported > To > Unsupported > Via > WWW-Authenticate > > Thanks > -- > Vladica Stanisic > Research Assistant > North Carolna State University > e-mail:vjstanis@eos.ncsu.edu > > > > __________________________________________________________________ > Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ > > Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.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 daemon@optimus.ietf.org Mon Mar 25 18:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07883 for ; Mon, 25 Mar 2002 18:29:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27133 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 18:29:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22084; Mon, 25 Mar 2002 18:08:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22052 for ; Mon, 25 Mar 2002 18:08:16 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07360 for ; Mon, 25 Mar 2002 18:08:12 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2PN7LI27594; Mon, 25 Mar 2002 15:07:21 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA19981; Mon, 25 Mar 2002 15:07:28 -0800 (PST) Message-ID: <3C9FADA7.4D3E8149@cisco.com> Date: Mon, 25 Mar 2002 18:07:19 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Dean Willis'" , sip@ietf.org, Rohan Mahy , jo@ipdialog.com, brian.rosen@marconi.com, wtm@research.att.com Subject: Re: [Sip] WGLC for Informational Draft on Media Authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > > > All, > > A very late but very small, and perhaps important, comment: the header > carries a hex string which contains a Policy Element as defined in > RFC2750, including length and P-Type. Should it be able to carry more > than one Policy Element ? Yes. > RSVP allows you to include more than one, and since the Policy > Elements can be of different types, the flexibility to include more > than one could be of value. > > Sinec the token in this header is just a hex string, including length > and type bytes, then the syntax can remain the same, and the procedure > at the UAs (copy the data into the appropriate place in the RSVP > POLICY-DATA object) remains the same. > The text already talks about having multiple Authorization Tokens, however this was added fairly late, and I forgot to bis-align the grammar. Updated grammar would be: P-Media-Authorization = "P-Media-Authorization" HCOLON P-Media-Authorization-Token *(COMMA P-Media-Authorization-Token) P-Media-Authorization-Token = 1*HEXDIG Unless I hear any objections, I will go ahead and make this change. Thanks for the comment Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Mar 25 21:08:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11286 for ; Mon, 25 Mar 2002 21:08:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05288 for sip-archive@odin.ietf.org; Mon, 25 Mar 2002 21:08:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28678; Mon, 25 Mar 2002 20:39:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28632 for ; Mon, 25 Mar 2002 20:39:10 -0500 (EST) Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10652 for ; Mon, 25 Mar 2002 20:39:06 -0500 (EST) Received: from victorpc ([206.184.140.167]) by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g2Q1cso04924; Mon, 25 Mar 2002 20:38:54 -0500 From: "Victor Paulsamy" To: , "Nagaraj" Cc: , Subject: RE: [Sip-implementors] Re: [Sip] Timeout condition in hold state Date: Mon, 25 Mar 2002 17:38:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Nagaraj, Take a look at http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-08.txt Another handy tool would be RTCP packets. Hope this helps. Regards, --victor Victor Paulsamy E-mail: victor@zapex.com Senior Software Engineer Phone : 650.930.1339 (Direct) Zapex Technologies, Inc. Phone : 650.930.1300 (Main) Mountain View, CA 94043 Fax : 650.930.1399 > -----Original Message----- > From: sip-implementors-admin@cs.columbia.edu > [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of > Tom_Gray@Mitel.COM > Sent: Monday, March 25, 2002 8:05 AM > To: Nagaraj > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > Subject: [Sip-implementors] Re: [Sip] Timeout condition in hold state > > > > This appears to be more concerned with specific call processing issues and > policies than with SIP. It should be handled outside of SIP. A similar > concern could be raised about long duration calls. A stateful proxy will > reserve resources for all calls. If no activity is seen on a call for a > significant period of time, what should be done? Currently in the PSTN in > North America, calls are terminated in the network if they have > been up for > 48 hours to preserve resources. I do not see this being as SIP issue as > well although it will need to be implemented on SIP-enable systems. > > > > > > > "Nagaraj" @ietf.org on 03/25/2002 01:15:32 AM > > Sent by: sip-admin@ietf.org > > > To: , > cc: > > Subject: [Sip] Timeout condition in hold state > > > > Hi all, > > Is there any쟰rovision쟧n SIP to take care of the timeout in holding > condition�? > > Consider a situation: > > ua-A� establishes a SIP session with ua-B. > After some time ua-B requests for a hold by using INVITE method. > ua-A goes into "hold" state and waits for ua-B to resume. > > If now network goes down at ua-B, and he disconnects without sending any > more SIP messages, > how ua-A will come to know about쟧t. > > Is there a mechanism for determining timeout쟶alue for ua-A, so that he > wont wait forever. > > Regards, > > -Nagaraj. > > > Nagaraj. Bhat. > Smart Yantra Technologies Pvt Ltd > #57, 3rd Floor, HMT Layout > Behind R.T. Nagar Police Station > R.T. Nagar > Bangalore - 560032 > Phone: 91-80-3634917 / 91-80-3634918 > Fax: 91-80-3631927 > > > Nagaraj_s_bhat@yahoo.com > Nagaraj.bhat@vsnl.com > nagaraj@smartyantra.com > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 00:53:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17301 for ; Tue, 26 Mar 2002 00:53:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27010 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 00:53:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19978; Tue, 26 Mar 2002 00:23:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19932 for ; Tue, 26 Mar 2002 00:23:00 -0500 (EST) Received: from hotmail.com (f16.law4.hotmail.com [216.33.149.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16436 for ; Tue, 26 Mar 2002 00:22:59 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 25 Mar 2002 21:22:30 -0800 Received: from 202.9.150.118 by lw4fd.law4.hotmail.msn.com with HTTP; Tue, 26 Mar 2002 05:22:29 GMT X-Originating-IP: [202.9.150.118] From: "kamala subramaniam" To: sip@ietf.org Date: Tue, 26 Mar 2002 05:22:29 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 26 Mar 2002 05:22:30.0190 (UTC) FILETIME=[39B42CE0:01C1D486] Subject: [Sip] SIP + healthcare systems Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org

Hi! I wanted to find out if there is some good literature on SIP with regards to healthcare systems and where I might be able to find them.

Thanks much -Kamala


Chat with friends online, try MSN Messenger: Click Here
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 02:02:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21856 for ; Tue, 26 Mar 2002 02:02:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14100 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 02:02:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08703; Tue, 26 Mar 2002 01:39:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08494 for ; Tue, 26 Mar 2002 01:39:30 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17836 for ; Tue, 26 Mar 2002 01:39:28 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 01:39:00 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39A96@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: "'sip@ietf.org '" Subject: RE: [Sip] Manyfolks: Unified local/remote model Date: Tue, 26 Mar 2002 01:38:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org in-line. Gonzalo, I'll make this my last one (if you will :-) though given the end of last call which I think is appropriate to unburden the list. I'll leave future feedback to a new draft (my only reasonable course) in a while which will cover more general requirements, the alternative general solution, our specific longerterm requirements and feature / efficiency comparisons to manyfolks work. Good luck with the IESG, Regards, Alan. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 25 March 2002 18:02 To: Alan O'Neill Cc: 'David R. Oran '; 'sip@ietf.org ' Subject: Re: [Sip] Manyfolks: Unified local/remote model Hello, The problem with your suggestion is that the offerer specifies what he will do, not what he wants. AWO> No the offer/answer combination says what each will do whilst the offerer says what it is prepared to do. This is fine since the requirement is always known and doesn't need to be signalling. "I want 'strength' end to end QoS please for this session in this direction please." For instance, if the offerer says "remote", it means (in your model) that he will perform resource reservations in the answerer's access network. But what we really want to say is: I want QoS in your access network. Do whatever to ensure that. AWO> No I say the same thing as you. The offerer is saying I want QoS in your access network by virtue of setting a precondition. If the answerer can, it will. If it can't the offerer can try to itself. The offerer saying remote can lead to four different answerer responses and four different sets of mechanism by the two endpoints. In eachc ase the response is clear about whether or not an update is needed. You claim that in manyfolks-05 the offerer chooses the status type (segmented or e2e) and that the answerer cannot change it. This is not a problem. If I ask for mandatory e2e, I do not want the answerer to change it to segmented. AWO> You don't want the change because of what these mean in your model, not because of any basic requirement about what we are trying to achieve. The requirement for preconditions is always e2e (pointless otherwise generally) so the only thing to resolve is who does what and the resulting feedback...The strength indicates what we should do if any QoS mech fails.. However, if I ask for segmented and I support e2e, it will be acceptable for me that the status type is changed from segmented to e2e. Manyfolks-05 already covers this, since the offerer will include mandatory local/remote and optional e2e (to indicate support for the e2e status type). The answerer can upgrade the e2e line to mandatory, and assume that the local/remote preconditions are met once the e2e preconditions are met. AWO> Sure so interoperability is obtained by doubling everything up in the offer, or by using a subsequent offer. Seems a shame somehow. Alan. > ---------------------------------------------------------------- > Notice Regarding Intellectual Property Rights > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > protection on some or all of the technical information submitted by its > employees in connection with the IETF's standards process. If part(s) of a > submission by Flarion is (are) included in a standard and Flarion owns > patent(s) and/or pending patent application(s) that are essential to > implementation of such included part(s) in said standard, Flarion is > prepared to grant a license on fair, reasonable, reciprocal (license back) > and non-discriminatory terms on such included part(s). > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 02:03:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23025 for ; Tue, 26 Mar 2002 02:03:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14292 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 02:03:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08635; Tue, 26 Mar 2002 01:39:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08453 for ; Tue, 26 Mar 2002 01:39:27 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17834 for ; Tue, 26 Mar 2002 01:39:25 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 01:38:57 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39A95@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: "'sip@ietf.org '" Date: Tue, 26 Mar 2002 01:38:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Manyfolks draft wording Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 25 March 2002 14:19 To: Alan O'Neill Cc: 'sip@ietf.org ' Subject: Re: Manyfolks draft wording Hello, > I stated that "e2e reservations do not 'necessarily' ensure end to end QoS". Yes, we have been speaking about this for a while already. What manyfolks provides you is a hook between the application and the reservation protocol. When the reservation protocol is an e2e protocol (e.g., RSVP), you need to know when the send and the recv directions are ready in order to resume session establishment. This framework assumes that when the reservation protocol says that the send direction is ready, it is true. What you are saying is that the framework should say: "when the other end tells you that the send direction is ready, don't believe it, because it is not necessarily so. e2e reservation protocols do not work, so the other end is missinformed when he states that resources in the send directions are reserved." AWO> Not what I am saying at all. If I have an SLA covering that end point and the networks in between then I can believe but if I do not then I cannot becasue no-one is going to book resources for me for nothing. You only believe the e2e protocol because of other knowledge you have with the 3G system that has an implied SLA with it. Basically, your protocol design relies on the fact that 3G will ensure all e2e tags are adequately supported in the core dimensioning and through PDPcontext activation in the access. This is an SLA covering 3G and yes this will work for 3G...The general case though is very different and hence why I am reacting to your design and the wording in the draft. What I am trying to say is that the fact that e2e reservation protocols may not ensure e2e QoS is not a problem of the framework but a problem of the reservation protocol itself. The manyfolks framework should not describe whether reservation protocols work or not. It only transports the information the resource reservation protocols provides (that is, the status of resource reservation as seen by the resource reservation protocol). aWO> No - it is not a problem with the protocol at all but of the framework because you do not in anyway cover SLAs (ie customer commitments). RSVP as an example books resources but they can only be booked if they are available to you from a policy perspective in the places you are trying to call..these are SLA issues. You have written a draft that states absolutes about QoS mechanisms that are in fact variables based on the deployment scenarion and associated SLAs...thats all. You are therefore 3G and DCS specific and unrepresentative of the rest of the net and how operators sell QoS.. Take into account that if you want preconditions to work, you have to trust the reservation protocol. If you receive a messages saying: "I have reserved resources in the send direction", and you do not trust it, preconditions are useless. Since you could not be sure whether or not the preconditions were met, you would never resume sessione establishment. AWO> Trusting the protocol is not at issue here..The protocol does not convey the information you require. If RSVP says there is a non-RSVP cloud you don't know where it is and therefore do not know what to do about. If the non-RSVP cloud is encountered within 3G you will interpret this as success, and so you must accept all non-RSVPs as a success becasue you will surely transition the 3G core in all VoIP cases, and you can't see if there are additional non-RSVP congested segments..In both case, the only way to resolve this in the gneral case is that you only trust the protocol if there is an SLA covering the path...end of story.. > In the manyfolks draft and in your follow-up to my wording issue you state > that segmented does not ensure QoS whilst e2e protocol does. Thereby you are > stating that segmented is somehow less able to satisfy preconditions and > hence, according to my concern, is considered worse in this specific regard. > If you use e2e status type, there is something in the SDP that tells you that there are e2e resources. As I said before, manyfolks assumes that you trusts your reservation protocol. AWO> But the UA doesn't know that and it is only known in your head becasue of what you know about 3G..ie the SLA. The reservation protocol will send non-RSVP cloud which you choose to ignore because of that SLA commitment.. when you use local/remote tags, there is nothing in the SDP that tells you anything about the backbone. Therefore, there may be resources or there may not be resources. The fact is that with the information in the SDP you cannot tell. AWO> That is an effect and assumption of the design and hence the root of my concern. In the case of DOCSIS DQoS I can run bi-RSVP to the CMTS and reserve the two accesses. In the CMTS I can have a dimensioned diff-serv cloud into which the bi-RSVP messages are admitted. I have not used e2e protocol but I have confirmed e2e QoS to the same level as assurance as when using the e2e tag. The SLA with my operator to a destination says whether in principle e2e QoS is possible. The SDP Update confirms that the QoS set-up within this SLA has succeeded. The only difference with the signalling is the added 0.5 RTT becasue I need to use an Update instead of the QoS protocol feedback. The draft is missing the SLA bit and the relative wighting of e2e v local/remote adn the associated assumptions are 3G/DCS specific but in general bogus. Please proceed if you and the working are happy that someone like me can in the future write a=des:QoS2 for my QoS mechs and assumptions, and we will forget about interoperability...sound reasonable ? (I hope not) Alan. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 02:04:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24251 for ; Tue, 26 Mar 2002 02:04:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14542 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 02:04:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08585; Tue, 26 Mar 2002 01:39:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08415 for ; Tue, 26 Mar 2002 01:39:25 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17830 for ; Tue, 26 Mar 2002 01:39:23 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 01:38:54 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39A93@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo Cc: "'sip@ietf.org '" Subject: RE: [Sip] Re: Manyfolks Clarifications Date: Tue, 26 Mar 2002 01:38:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So a 3G node and another node outside of the 3G cloud, both of which have segmented models on their accesses, and the same SLAs for vocie with a common core cannot set-up voice calls with preconditions..is that what you are saying ? And the same for a DCS node contacting a peer outside of its cloud.. Are you sure that is the requirement and that 3G/DCS/CableLabs are happy with that ?? Alan. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 25 March 2002 14:25 To: Alan O'Neill Cc: 'sip@ietf.org ' Subject: Re: [Sip] Re: Manyfolks Clarifications Hello, > Then what should a DCS UA use to a 3G UA and visaversa ? 3G clients will use the segmented status type to speak between them. When a call goes outside the IMS, if 3G terminals support any e2e protocol they can use mandatory e2e. If they don't, they simply cannot reserve network resources towards the other end. > And what should DCS and 3G use to an existing Internet host (say connected > to Worldcom), and visaversa ? Same as above. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 02:05:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24700 for ; Tue, 26 Mar 2002 02:05:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14633 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 02:05:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08476; Tue, 26 Mar 2002 01:39:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08407 for ; Tue, 26 Mar 2002 01:39:23 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17828 for ; Tue, 26 Mar 2002 01:39:21 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 01:38:52 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39A92@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo , "Alan O'Neill" Cc: "'sip@ietf.org '" Subject: RE: [Sip] Manyfolks: Unified local/remote model Date: Tue, 26 Mar 2002 01:38:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My problem is exactly that, which is that it is 3G and DCS specific with lots of assumptions about these deployments thrown in. I do not believe it adequately deals with the rest of the existing Internet, nor between the three of them. I also do not like the fact that e2e and local/remote are distinct tags, and that significant assumptions are made about what these tags mean from the specific existing/planned deployments. I specifically dislike the fact that somehow e2e is being coloured as magic cf segmented. I can draw scenarios in which both in conjunction with SLAs and Updates guarantee exactly the same, e2e less or e2e more, as can many on this list I am sure. Hence my dislike of that particular phrase about segmented which is frankly incorrect. e2e has advantages and disadvantages wrt segmented in the areas of overhead, RTTs, required degree of diff-serv dimensioning, levewl of assurance etc depending on the deployment. This will force the building of a=des:qos2 tags later on which is a shame but I guess where we will have to go if you so badly want to get this out of the door. Neither what you are suggesting nor the unified approach actually deals with my longer term company requirements, and what I believe is actually the general solution anyway but I deliberately avoided throwing that in as that would have kept us going for months. I am only seeking the best interim solution given the available timescales that ensures that future support for the wider model is possible and that interoperability will be efficient.. Alan. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 25 March 2002 18:02 To: Alan O'Neill Cc: 'David R. Oran '; 'sip@ietf.org ' Subject: Re: [Sip] Manyfolks: Unified local/remote model Hello, The problem with your suggestion is that the offerer specifies what he will do, not what he wants. For instance, if the offerer says "remote", it means (in your model) that he will perform resource reservations in the answerer's access network. But what we really want to say is: I want QoS in your access network. Do whatever to ensure that. You claim that in manyfolks-05 the offerer chooses the status type (segmented or e2e) and that the answerer cannot change it. This is not a problem. If I ask for mandatory e2e, I do not want the answerer to change it to segmented. However, if I ask for segmented and I support e2e, it will be acceptable for me that the status type is changed from segmented to e2e. Manyfolks-05 already covers this, since the offerer will include mandatory local/remote and optional e2e (to indicate support for the e2e status type). The answerer can upgrade the e2e line to mandatory, and assume that the local/remote preconditions are met once the e2e preconditions are met. Alan, the current manyfolks mechanism is what DCS and 3GPP want. Everything they need in their call flows is covered by manyfolks-05. Which is the scenario you have in mind that we do not currently cover? Thanks, Gonzalo Alan O'Neill wrote: > > Dave, > > Here is one way to view local/remote and e2e which I believe better supports > inter-domain preconditions. This is through the removal of the two distinct > status types because they are a barrier to efficient offer/answer > negotiation between heterogeneous domains, specifically because you need to > use a new offer if a UA starts with the wrong status type. It also requires > two sets of processing rules which is unnecessarily complex and avoids the > e2e v segmented beauty contest..It certainly is not a design though just a > way to represent the ideas. > > As before, all preconditions should be assumed to be a request for end to > end resources in the direction indicated by the direction tag. As before all > preconditions requests are e2e in nature but the QoS mechanisms supporting > these may not be. The current status reflects where we are compared to the > desired status. Offerer offers, the answerer answers, and Update is used > where necessary for confirmation. Precondition directions as always are wrt > to the SDP sender > > But lets instead use nill, local, remote and localremote where localremote > implies the availability of an end to end QoS protocol. From the view of two > UAs, localremote is as much as we can negotiate as neither UA knows anything > about the core in reality, even with an end to end protocol. > > The offerer follows manyfolks-05 and selects between nill, local, remote, > localremote as to its desired status towards meeting preconditions in the > specific direction. The answerer can then select from the offered desired > status and can specifically choose a subset or move from segmented to e2e > models. This is achieved by both the desired status and strength being > negotiable with the answerer responding to the offerer. > > Lets assume for direction caller(offerer) to callee(answerer) we have an > optional precondition. > > caller sends a=des:qos optional X send > callee sends a=des:qos optional Y recv > > Note that both ends keep there own view of what they have to do to meet > precondition so offerer/answerer des lines are different in each direction. > For below note RSVP is used as one example of a protocol giving feedback).. > > Actual Actual > Offered X Answered Y Meaning > nill nill Nothing will be booked > local Answerer happy to book its > end > remote Answerer books other end using RSVP > but local RSVP not supported. > localremote eg e2e via e2e signalling eg > RSVP attempted by answerer for both ends > local nill Answerer won't book > anything, offerer can > local e2e via segmented model > remote Answerer will book resources using > say RSVP > localremote e2e via e2e signalling eg > RSVP attempted by answerer for both ends > remote nill Anwerer won't book anything,left to > offerer > local Answerer happy to book its > end > remote Inverse segmented - each doing other > ends QoS (maybe for policy reasons ?) > localremote e2e via e2e signalling eg > RSVP attempted by answerer for both ends > localremote nill Happy for offerer to do e2e > via e2e signaling > local Switch to segmented model > with each doing local > remote switch to inverse segmented model > (each doing the others end) > localremote answerer over-rules and > wishes to book > > Of course the answerer can also respond with 'none' strength to cancel the > offered precondition, or stengthen it to 'mandatory' to tighten the > requirement for the desired status for the offerer. The offerers SDP should > now reflect the change requested by the answerer and no additional desired > status negotiation is possible through updates, which only affect current > status (I think that is optimal) > > Now at this point both ends know what needs to be done, and by whom..If > offerer is not happy it can re-offer or end the call-leg. Otherwise we move > to the current-status aspects... > > The current-status of the offerer will limit the flexibility open to the > answerer, in its response to the offered desired status, by including > information indicating that the offerer is starting the booking of, or > announcing the availability of, resources matching the offerers desired > status. The answerer should not modify the desired status by contravening > the current status of the offerer. > > The current status and each end then moves towards the desired status. The > callee should not alert until the preconditions are met and the caller > should send an Update when it learns additional information not known to the > callee about the current status via changes in its local booking and its > booking of remote resources, whether as part of a segmented, inverse > segmented or end to end signalling model. > > I hope I having missed anything and that the addition of an integrated > local, remote, localremote model eliminates two competing approaches and the > risk of the offerer starting with the wrong model. I hope I haven't missed > anything but this is kin of where I was going with my analysis... > > Alan. > > ---------------------------------------------------------------- > Notice Regarding Intellectual Property Rights > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > protection on some or all of the technical information submitted by its > employees in connection with the IETF's standards process. If part(s) of a > submission by Flarion is (are) included in a standard and Flarion owns > patent(s) and/or pending patent application(s) that are essential to > implementation of such included part(s) in said standard, Flarion is > prepared to grant a license on fair, reasonable, reciprocal (license back) > and non-discriminatory terms on such included part(s). > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Tue Mar 26 02:05:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25255 for ; Tue, 26 Mar 2002 02:05:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14733 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 02:05:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08529; Tue, 26 Mar 2002 01:39:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08417 for ; Tue, 26 Mar 2002 01:39:25 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17831 for ; Tue, 26 Mar 2002 01:39:23 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 01:38:54 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39A94@ftmail> From: "Alan O'Neill" To: Christian Huitema , Gonzalo Camarillo Cc: sip@ietf.org Subject: RE: [Sip] Manyfolks: Unified local/remote model Date: Tue, 26 Mar 2002 01:38:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Christian, I have a lot of sympathy for your position Christian but would in addition note that only the reach and the stength of the operators SLA with you is sufficient to potentially avoid the need for the average user to perform that continuity test. The QoS SLA is the mechansim by which an operator and its peers within the SLA reach, is forced to do the right thing from a dimensioning perspective. The customer buys the SLA strength/reach commensurate with its preferred level of call blocking, call degradation probability. In this model, the continuity test is a reactive mechanism as to why I am having problems rather than front loaded on all call set-ups, the majority of which will be fine. This also covers the problem of the continuity test being fine on call-set up but instantaneous conditions changing. Alan. -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: 25 March 2002 18:03 To: Gonzalo Camarillo; Alan O'Neill Cc: David R. Oran ; sip@ietf.org Subject: RE: [Sip] Manyfolks: Unified local/remote model > The problem with your suggestion is that the offerer specifies what he > will do, not what he wants. For instance, if the offerer says "remote", > it means (in your model) that he will perform resource reservations in > the answerer's access network. But what we really want to say is: I want > QoS in your access network. Do whatever to ensure that. The problem with QoS signaling is that it may or may not reflect any change of state in the network. The only way to be sure that there is available bandwidth is to perform a continuity test -- and even that will only give us an "instant snapshot", rather than a guarantee that the bw will still be available in the future. In fact, the continuity test would be very useful in many scenarios, regardless of QoS. In today's world of firewalls and NATs, I can see many cases in which two parties successfully negotiate codecs and other SDP parameters, and then find out that they cannot actually communicate. The same considerations that drove the DCS effort apply: we should perform an RTP continuity test before ringing the called party... -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 04:37:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28136 for ; Tue, 26 Mar 2002 04:37:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20653 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 04:37:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12200; Tue, 26 Mar 2002 04:01:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12163 for ; Tue, 26 Mar 2002 04:01:16 -0500 (EST) Received: from mx3.tellabs.com (mx3.tellabs.com [204.68.180.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27828 for ; Tue, 26 Mar 2002 04:01:13 -0500 (EST) Received: from maile01.tellabs.fi (maile01.tellabs.fi [193.64.171.209]) by mx3.tellabs.com (Mirapoint) with ESMTP id AEX88237; Tue, 26 Mar 2002 03:00:43 -0600 (CST) Received: from tellabs.com (dhcp-172-19-13-153.tellabs.fi [172.19.13.153]) by maile01.tellabs.fi with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id LAA08456; Tue, 26 Mar 2002 11:00:41 +0200 (EET) Message-ID: <3CA038B8.7A5BF408@tellabs.com> Date: Tue, 26 Mar 2002 11:00:40 +0200 From: Tapio Lehtonen X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: fi,en,sv,de,fr MIME-Version: 1.0 To: kamala subramaniam CC: sip@ietf.org Subject: Re: [Sip] SIP + healthcare systems References: Content-Type: multipart/mixed; boundary="------------D8A6FD0062468F0D798E7EE4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------D8A6FD0062468F0D798E7EE4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I'm not sure what special SIP related issues healtcare has, but you can read more about SIP in http://www.ietf.org/html.charters/sip-charter.html and perhasp from SIPPING, which might be more appropriate for your application area needs. I quote from SIPPING charter: "The Session Initiation Protocol Project INvestiGation (SIPPING) working group is chartered to document the use of SIP for several applications related to telephony and multimedia, and to develop requirements for any extensions to SIP needed for those applications. Such requirements will be referred to the SIP working group for development of any new SIP method or header. Guiding principles for the performance of SIPPING's work will include: " which you can get from http://www.ietf.org/html.charters/sipping-charter.html By the way, SIPPING mailing list is more appropriate for discussion about SIP application area issues, you should address your additional questions there. kamala subramaniam wrote: > > Hi! I wanted to find out if there is some good literature on SIP with > regards to healthcare systems and where I might be able to find them. > > Thanks much -Kamala > > ---------------------------------------------------------------------- > Chat with friends online, try MSN Messenger: Click Here > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip -- ==================================================================== Tapio Lehtonen tel: +358 9 4131 2206 Tellabs Oy fax: +358 9 4131 2030 Sinim�entie 6 email: Tapio.Lehtonen@Tellabs.COM FIN-02630 ESPOO URL http://www.Tellabs.com/ Finland Senior Design Engineer ==================================================================== --------------D8A6FD0062468F0D798E7EE4 Content-Type: text/x-vcard; charset=us-ascii; name="tapio.lehtonen.vcf" Content-Description: Card for Tapio Lehtonen Content-Disposition: attachment; filename="tapio.lehtonen.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Lehtonen;Tapio tel;cell:+358 40 590 1324 tel;fax:2030 tel;work:2206 x-mozilla-html:FALSE url:http://rd-www.tellabs.fi/~tapio org:SE&PP adr:;;Sinim�entie 6;Espoo;;FI-02630;Finland version:2.1 email;internet:Tapio.Lehtonen@Tellabs.COM title:Senior Design Engineer fn:Tapio Lehtonen end:vcard --------------D8A6FD0062468F0D798E7EE4 Content-type: text/plain Content-Disposition: inline ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ --------------D8A6FD0062468F0D798E7EE4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 06:30:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29084 for ; Tue, 26 Mar 2002 06:30:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA16484 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 06:30:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20019; Tue, 26 Mar 2002 04:34:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19971 for ; Tue, 26 Mar 2002 04:34:47 -0500 (EST) Received: from gw-nl5.philips.com (gw-nl5.philips.com [212.153.235.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28116 for ; Tue, 26 Mar 2002 04:34:43 -0500 (EST) From: frank.derks@philips.com Received: from smtpscan-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl5.philips.com with ESMTP id KAA26146 for ; Tue, 26 Mar 2002 10:34:40 +0100 (MET) (envelope-from frank.derks@philips.com) Received: from smtpscan-nl1.philips.com(130.139.36.21) by gw-nl5.philips.com via mwrap (4.0a) id xma026143; Tue, 26 Mar 02 10:34:41 +0100 Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA15400 for ; Tue, 26 Mar 2002 10:34:38 +0100 (MET) Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA06750 for ; Tue, 26 Mar 2002 10:34:36 +0100 (MET) To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 26 Mar 2002 10:33:17 +0100 X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 26/03/2002 10:35:29, Serialize complete at 26/03/2002 10:35:29 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0034677FC1256B88_=" Subject: [Sip] Timer D in the INVITE client transaction MUST inform the TU when it fires???? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multipart message in MIME format. --=_alternative 0034677FC1256B88_= Content-Type: text/plain; charset="us-ascii" 17.1.12 (lines 3312, 3313) states: "If timer D fires while the client transaction is in the "Completed" state, the client transaction MUST move to the terminated state, and it MUST inform the TU of the timeout." This does not apply to the cases when timers I, J, K fire in the other types of transactions. Moreover, I do not think that the above statement for timer D is correct: there is no purpose in informing the transaction user. The sentence should therefore be removed. Regards, Frank --=_alternative 0034677FC1256B88_= Content-Type: text/html; charset="us-ascii"
17.1.12 (lines 3312, 3313) states:

"If timer D fires while the client transaction is in the "Completed" state,
 the client transaction MUST move to the terminated state, and it MUST
 inform the TU of the timeout."

This does not apply to the cases when timers I, J, K fire in the other types
of transactions. Moreover, I do not think that the above statement for timer
D is correct: there is no purpose in informing the transaction user. The
sentence should therefore be removed.

Regards,

Frank --=_alternative 0034677FC1256B88_=-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 08:43:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02361 for ; Tue, 26 Mar 2002 08:43:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA18501 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 08:44:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA10966; Tue, 26 Mar 2002 08:16:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA09943 for ; Mon, 25 Mar 2002 23:41:51 -0500 (EST) Received: from ganga.smartyantra.co.in (IDENT:root@[202.142.72.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15864 for ; Mon, 25 Mar 2002 23:41:45 -0500 (EST) Received: from godavari ([192.168.1.47]) by ganga.smartyantra.co.in (8.11.0/8.11.0) with SMTP id g2Q4oAD27340; Tue, 26 Mar 2002 10:20:18 +0530 Message-ID: <003501c1d481$da47e8e0$2f01a8c0@godavari> From: "Nagaraj" To: "Victor Paulsamy" , Cc: , References: Subject: Re: [Sip-implementors] Re: [Sip] Timeout condition in hold state Date: Tue, 26 Mar 2002 10:20:57 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thnx for the solution. Regards. -Nagaraj. ----- Original Message ----- From: "Victor Paulsamy" To: ; "Nagaraj" Cc: ; Sent: Tuesday, March 26, 2002 7:08 AM Subject: RE: [Sip-implementors] Re: [Sip] Timeout condition in hold state > Nagaraj, > > Take a look at > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-08.txt > > Another handy tool would be RTCP packets. Hope this helps. > > Regards, > > --victor > > Victor Paulsamy E-mail: victor@zapex.com > Senior Software Engineer Phone : 650.930.1339 (Direct) > Zapex Technologies, Inc. Phone : 650.930.1300 (Main) > Mountain View, CA 94043 Fax : 650.930.1399 > > > -----Original Message----- > > From: sip-implementors-admin@cs.columbia.edu > > [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of > > Tom_Gray@Mitel.COM > > Sent: Monday, March 25, 2002 8:05 AM > > To: Nagaraj > > Cc: sip@ietf.org; sip-implementors@cs.columbia.edu > > Subject: [Sip-implementors] Re: [Sip] Timeout condition in hold state > > > > > > > > This appears to be more concerned with specific call processing issues and > > policies than with SIP. It should be handled outside of SIP. A similar > > concern could be raised about long duration calls. A stateful proxy will > > reserve resources for all calls. If no activity is seen on a call for a > > significant period of time, what should be done? Currently in the PSTN in > > North America, calls are terminated in the network if they have > > been up for > > 48 hours to preserve resources. I do not see this being as SIP issue as > > well although it will need to be implemented on SIP-enable systems. > > > > > > > > > > > > > > "Nagaraj" @ietf.org on 03/25/2002 01:15:32 AM > > > > Sent by: sip-admin@ietf.org > > > > > > To: , > > cc: > > > > Subject: [Sip] Timeout condition in hold state > > > > > > > > Hi all, > > > > Is there any provision in SIP to take care of the timeout in holding > > condition ? > > > > Consider a situation: > > > > ua-A establishes a SIP session with ua-B. > > After some time ua-B requests for a hold by using INVITE method. > > ua-A goes into "hold" state and waits for ua-B to resume. > > > > If now network goes down at ua-B, and he disconnects without sending any > > more SIP messages, > > how ua-A will come to know about it. > > > > Is there a mechanism for determining timeout value for ua-A, so that he > > wont wait forever. > > > > Regards, > > > > -Nagaraj. > > > > > > Nagaraj. Bhat. > > Smart Yantra Technologies Pvt Ltd > > #57, 3rd Floor, HMT Layout > > Behind R.T. Nagar Police Station > > R.T. Nagar > > Bangalore - 560032 > > Phone: 91-80-3634917 / 91-80-3634918 > > Fax: 91-80-3631927 > > > > > > Nagaraj_s_bhat@yahoo.com > > Nagaraj.bhat@vsnl.com > > nagaraj@smartyantra.com > > > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 10:03:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05259 for ; Tue, 26 Mar 2002 10:03:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA09640 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 10:03:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04115; Tue, 26 Mar 2002 09:42:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04078 for ; Tue, 26 Mar 2002 09:42:40 -0500 (EST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04553 for ; Tue, 26 Mar 2002 09:42:37 -0500 (EST) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g2QEgdX07191 for ; Tue, 26 Mar 2002 15:42:39 +0100 (MET) Received: from christine.mchp.siemens.de (christine.mchp.siemens.de [139.23.186.70]) by mail2.siemens.de (8.11.6/8.11.6) with ESMTP id g2QEgdC19929 for ; Tue, 26 Mar 2002 15:42:39 +0100 (MET) Received: from mhpa8r1c (mhpa8r1c.mchp.siemens.de [139.23.185.114]) by christine.mchp.siemens.de (8.11.6+Sun/8.11.6) with ESMTP id g2QEgai21337 for ; Tue, 26 Mar 2002 15:42:37 +0100 (MET) From: "Salva Rey Calatayud" To: sip@ietf.org Date: Sun, 26 Mar 2000 16:54:16 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Reply-to: salreyca@teleco.upv.es Message-ID: <38DE40B8.20609.14E4303@localhost> Priority: normal X-mailer: Pegasus Mail for Win32 (v3.12cDE) Content-Transfer-Encoding: 7BIT Subject: [Sip] O/A model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7BIT Hi, how should a UA act when let's say the other endpoint doesn't behave compliantly to the O/A exchange model. For instance, we send an offer, and none of the associated messages that could contain an answer does (an UPDATE with a 200OK without answer, INVITE with offer and none of the provisional response nor final 200OK contain an answer ) thanks, Salva _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 11:00:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08154 for ; Tue, 26 Mar 2002 11:00:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26915 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 11:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17493; Tue, 26 Mar 2002 10:28:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17444 for ; Tue, 26 Mar 2002 10:28:12 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06546 for ; Tue, 26 Mar 2002 10:28:09 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2QFRSs20758; Tue, 26 Mar 2002 09:27:28 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 09:27:29 -0600 Message-ID: From: "Ben Wang" To: "Peterson, Jon" Cc: sip@ietf.org, "Ben Wang" Subject: RE: [Sip] comments on privacy-04 Date: Tue, 26 Mar 2002 09:27:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D4DA.BC1498B0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D4DA.BC1498B0 Content-Type: text/plain; charset="iso-8859-1" Hi Jon, Quick comments on your comments inline on rpi-pty-type :-) Regards, Ben -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Monday, March 18, 2002 11:04 AM To: 'sip@ietf.org' Subject: [Sip] comments on privacy-04 - rpi-pty-type: This parameter allows you to specify which party's identity is contained in the RPID header ("calling" or "called" are currently allowed). However, no motivation for this capability is presented in the draft - it defines the conditions under which these parameters are inserted, but there is no recipient behavior that justifies their insertion. Moreover, the behavior for adding the parameter holds only that a request contains a 'calling' id, and the response contains a 'called' id. This sounds right - I'd imagine that a privacy mechanism would use the RPID header to express the private identity of the sender of a message; and in fact, if the rpi-id-type header is not present, that's exactly what the recipient assumes. So in short the motivation for this parameter isn't clear. If there is a need for it then the draft should describe it, otherwise, I think this parameter should be removed, since the default behavior seems appropriate. [BW]In my personal opinion, I think RPID privides a viable mechanism for identity assertion by proxy servers to communicate more "call state information" to service platform or gateways to legacy networks. To enable more advanced personlized services, a proxy server, in addition to inserting RPID of "calling party", it could insert RPID about "called party", "redirecting party" etc in a request message. This identity assertion mechanism could also make interworking with legacy network much easier. ------_=_NextPart_001_01C1D4DA.BC1498B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] comments on privacy-04

Hi Jon,

Quick comments on your comments inline on = rpi-pty-type :-)

Regards,
Ben

-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
Sent: Monday, March 18, 2002 11:04 AM
To: 'sip@ietf.org'
Subject: [Sip] comments on privacy-04



- rpi-pty-type: This parameter allows you to specify = which party's identity
is contained in the RPID header ("calling" = or "called" are currently
allowed). However, no motivation for this capability = is presented in the
draft - it defines the conditions under which these = parameters are inserted,
but there is no recipient behavior that justifies = their insertion. Moreover,
the behavior for adding the parameter holds only = that a request contains a
'calling' id, and the response contains a 'called' = id. This sounds right -
I'd imagine that a privacy mechanism would use the = RPID header to express
the private identity of the sender of a message; and = in fact, if the
rpi-id-type header is not present, that's exactly = what the recipient
assumes. So in short the motivation for this = parameter isn't clear. If there
is a need for it then the draft should describe it, = otherwise, I think this
parameter should be removed, since the default = behavior seems appropriate.

[BW]In my personal opinion, I think RPID privides a = viable mechanism for identity assertion by proxy servers to communicate = more "call state information" to service platform or gateways = to legacy networks. To enable more advanced personlized services, a = proxy server, in addition to inserting RPID of "calling = party", it could insert RPID about "called party", = "redirecting party" etc in a request message. This identity = assertion mechanism could also make interworking with legacy network = much easier.

 

------_=_NextPart_001_01C1D4DA.BC1498B0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 11:25:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09541 for ; Tue, 26 Mar 2002 11:25:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04249 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 11:25:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26601; Tue, 26 Mar 2002 10:58:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26559 for ; Tue, 26 Mar 2002 10:58:45 -0500 (EST) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08080 for ; Tue, 26 Mar 2002 10:58:40 -0500 (EST) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.icomverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g2QFlOU19786 for ; Tue, 26 Mar 2002 17:47:24 +0200 Received: by il-tlv-mbdg2.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Mar 2002 17:58:38 +0200 Message-ID: From: "Fuxbruner, Amihay" To: sip@ietf.org Subject: [Sip] Using ACK for dialog validation Date: Tue, 26 Mar 2002 17:58:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D4DF.16DD9360" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D4DF.16DD9360 Content-Type: text/plain; charset="windows-1255" Hi, Bis 09 says ACK must be sent for each 2xx response of INVITE. Does it means we can send 2xx and receive ACK during a session as a means for dialog validation ? Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C1D4DF.16DD9360 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable [Sip] Using ACK for dialog validation

Hi,

Bis 09 says ACK must be sent for each = 2xx response of INVITE. Does it means we can send 2xx and receive ACK = during a session as a means for dialog validation ?

Thanks,

Amihay Fuxbruner
System Engineering - Signaling = R&D
Comverse

------_=_NextPart_001_01C1D4DF.16DD9360-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 12:37:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14644 for ; Tue, 26 Mar 2002 12:37:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27017 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 12:37:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21566; Tue, 26 Mar 2002 12:20:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21531 for ; Tue, 26 Mar 2002 12:20:06 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13514 for ; Tue, 26 Mar 2002 12:19:57 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g2QHJxoq008141 for ; Tue, 26 Mar 2002 18:19:59 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.32]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2QHJxUD012654 for ; Tue, 26 Mar 2002 19:19:59 +0200 (EET) Message-ID: <3CA0ADC1.71DBB8@lmf.ericsson.se> Date: Tue, 26 Mar 2002 19:20:01 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'sip@ietf.org'" Subject: Re: [Sip] non-SIP-URI and tag References: <0154633DAF7BD4119C360002A513AA030220EFCF@efijont102> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Any comments/clarifications on this? Regards, Christer Holmberg Ericsson Finland "Christer Holmberg (LMF)" wrote: > Hi, > > As we have discussed before, if a SIP-URI contains URI parameters the URI must be put between brackets. Otherwise the parameters will be regarded as header parameter (eg the tag parameter). > > Now, since we are allowed to use other kinds of URIs in the To- and From headers (my client may not know the specific semantics of those), and the ABNF allows those URIs to contain the ";" characters (which are used to separate parameters in the SIP-URI), does this mean that ALL URIs must be put within brackets if they contain the ";" character - even if it doesn't have anything to do with URI parameters (I assume that is possible)? > > Otherwise, when my parser finds a ";" character when parsing the non-SIP-URI, how does it now if the character is simply a character within some part of the URI, or if it separates URI parameters, or if it separates the URI from the rest of the header? > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Mar 26 12:38:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14679 for ; Tue, 26 Mar 2002 12:38:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27187 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 12:38:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20701; Tue, 26 Mar 2002 12:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20573 for ; Tue, 26 Mar 2002 12:17:39 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13363 for ; Tue, 26 Mar 2002 12:17:35 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2QHH7i22086; Tue, 26 Mar 2002 11:17:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2QHH7T04742; Tue, 26 Mar 2002 11:17:07 -0600 (CST) Received: from lmf.ericsson.se (rmt160154.am.ericsson.se [138.85.160.154]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA08727; Tue, 26 Mar 2002 11:17:04 -0600 (CST) Message-ID: <3CA0ADDE.555D4CEF@lmf.ericsson.se> Date: Tue, 26 Mar 2002 19:20:30 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Alan O'Neill" CC: "'sip@ietf.org '" Subject: Re: [Sip] Manyfolks: Unified local/remote model References: <8C92E23A3E87FB479988285F9E22BE46C39A96@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Alan, A few clarifications. 1) When you talk about "my design" (which is wrong in your opinion) you are talking about a mechanism that was designed by a bunch of people which did not include myself, and was available in the WG for comments for a long while. The fact that I am the editor now does not make this draft "my design". It is the design of many people. 2) you claim that I want to "get this out of the door as soon as possible". This is not the first time that folks in the WG complain because we try to meet the deadlines. When we were finishing the SIP spec (bis), folks in the WG also complained... as Jonathan said then, it is unfair that people within the WG, rather than recognizing the incredible amount of work, including evenings, nights and weekends, that we all have put into both bundle 1 and 2, are only complaining about "our" designs. In order to meet the deadlines, we need commited authors and also commited reviewers. The fact that folks wait until the end to throw comments about the whole contents of the draft , is not the author's fault. The manyfolks mechanism has been available for review a long time ago already... and the new additions to manyfolks-04 were discussed in the mailing list a long while before manyfolks-04 was actually released. 3) You have already mentioned several times the "beauty contest" between e2e and segmented. As far as I know, you are the only one saying that one is better than the other. As I said previously, both have advantages and disadvantages, and the draft does not state that one is better or preferrable than the other. Anyway, if you want me to remove the sentece that troubles you so much (the one that says that the segmented status type does not say anything about the backbone), I can remove it. It is only motivational text, and if you feel so unconfortable with the sentence, I will get rid of it (although I still think that it is a perfectly OK sentence). Let me know how you want me to proceed on this. 4) This draft has been around for a long while, and you are throwing your comments a few days before WGLC is finished (which is alright). Since it seems that many people in the WG are happy with this solution, and what you want is a brand new solution, since the current one is completely useless for your needs, I believe that you should write a contribution (as you suggested) which will be available for everybody in the near future. Due to unfortunate time constrains that don't depend on me, we cannot wait for it before the IESG last call. Anyway, I believe that we are missunderstanding each other. If you want to discuss any issue related to this mail thread or to this draft, feel free to give me a call to +1 212 939 7171 (New York time zone). We may be able to get a better understanding of the problem on the phone than we have done on the mail so far. If the time difference makes it impossible for you to call me during office hours, let me know in a personal mail and I can try to arrange a conference bridge at a suitable time. Best regards, Gonzalo Alan O'Neill wrote: > > in-line. > > Gonzalo, > > I'll make this my last one (if you will :-) though given the end of last > call which I think is appropriate to unburden the list. I'll leave future > feedback to a new draft (my only reasonable course) in a while which will > cover more general requirements, the alternative general solution, our > specific longerterm requirements and feature / efficiency comparisons to > manyfolks work. > > Good luck with the IESG, > > Regards, Alan. > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 25 March 2002 18:02 > To: Alan O'Neill > Cc: 'David R. Oran '; 'sip@ietf.org ' > Subject: Re: [Sip] Manyfolks: Unified local/remote model > > Hello, > > The problem with your suggestion is that the offerer specifies what he > will do, not what he wants. > > AWO> No the offer/answer combination says what each will do whilst the > offerer says what it is prepared to do. This is fine since the requirement > is always known and doesn't need to be signalling. "I want 'strength' end to > end QoS please for this session in this direction please." > > For instance, if the offerer says "remote", > it means (in your model) that he will perform resource reservations in > the answerer's access network. But what we really want to say is: I want > QoS in your access network. Do whatever to ensure that. > > AWO> No I say the same thing as you. The offerer is saying I want QoS in > your access network by virtue of setting a precondition. If the answerer > can, it will. If it can't the offerer can try to itself. The offerer saying > remote can lead to four different answerer responses and four different sets > of mechanism by the two endpoints. In eachc ase the response is clear about > whether or not an update is needed. > > You claim that in manyfolks-05 the offerer chooses the status type > (segmented or e2e) and that the answerer cannot change it. This is not a > problem. If I ask for mandatory e2e, I do not want the answerer to > change it to segmented. > > AWO> You don't want the change because of what these mean in your model, not > because of any basic requirement about what we are trying to achieve. The > requirement for preconditions is always e2e (pointless otherwise generally) > so the only thing to resolve is who does what and the resulting > feedback...The strength indicates what we should do if any QoS mech fails.. > > However, if I ask for segmented and I support > e2e, it will be acceptable for me that the status type is changed from > segmented to e2e. Manyfolks-05 already covers this, since the offerer > will include mandatory local/remote and optional e2e (to indicate > support for the e2e status type). The answerer can upgrade the e2e line > to mandatory, and assume that the local/remote preconditions are met > once the e2e preconditions are met. > > AWO> Sure so interoperability is obtained by doubling everything up in the > offer, or by using a subsequent offer. Seems a shame somehow. > > Alan. > > > ---------------------------------------------------------------- > > Notice Regarding Intellectual Property Rights > > > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > > protection on some or all of the technical information submitted by its > > employees in connection with the IETF's standards process. If part(s) of > a > > submission by Flarion is (are) included in a standard and Flarion owns > > patent(s) and/or pending patent application(s) that are essential to > > implementation of such included part(s) in said standard, Flarion is > > prepared to grant a license on fair, reasonable, reciprocal (license back) > > and non-discriminatory terms on such included part(s). > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@optimus.ietf.org Tue Mar 26 13:49:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18715 for ; Tue, 26 Mar 2002 13:49:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16692 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 13:49:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11528; Tue, 26 Mar 2002 13:29:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11488 for ; Tue, 26 Mar 2002 13:29:03 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17619 for ; Tue, 26 Mar 2002 13:29:00 -0500 (EST) Message-ID: <20020326182902.80852.qmail@web11603.mail.yahoo.com> Received: from [131.107.3.85] by web11603.mail.yahoo.com via HTTP; Tue, 26 Mar 2002 10:29:02 PST Date: Tue, 26 Mar 2002 10:29:02 -0800 (PST) From: Sean Olson Subject: Re: [Sip] non-SIP-URI and tag To: Christer Holmberg , "'sip@ietf.org'" In-Reply-To: <3CA0ADC1.71DBB8@lmf.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Consistency is best. If the URI is not in angle brackets, the semicolon should mark the end of the URI and the start of the addr-spec parameters. /sean --- Christer Holmberg wrote: > > Any comments/clarifications on this? > > Regards, > > Christer Holmberg > Ericsson Finland > > "Christer Holmberg (LMF)" wrote: > > > Hi, > > > > As we have discussed before, if a SIP-URI contains > URI parameters the URI must be put between brackets. > Otherwise the parameters will be regarded as header > parameter (eg the tag parameter). > > > > Now, since we are allowed to use other kinds of > URIs in the To- and From headers (my client may not > know the specific semantics of those), and the ABNF > allows those URIs to contain the ";" characters > (which are used to separate parameters in the > SIP-URI), does this mean that ALL URIs must be put > within brackets if they contain the ";" character - > even if it doesn't have anything to do with URI > parameters (I assume that is possible)? > > > > Otherwise, when my parser finds a ";" character > when parsing the non-SIP-URI, how does it now if the > character is simply a character within some part of > the URI, or if it separates URI parameters, or if it > separates the URI from the rest of the header? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 26 16:20:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24679 for ; Tue, 26 Mar 2002 16:20:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA27229 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 16:20:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21441; Tue, 26 Mar 2002 16:01:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21399 for ; Tue, 26 Mar 2002 16:01:24 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23533 for ; Tue, 26 Mar 2002 16:01:20 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2QL0qU14736 for ; Tue, 26 Mar 2002 15:00:52 -0600 From: "Dean Willis" To: Date: Tue, 26 Mar 2002 15:00:28 -0600 Message-ID: <00d901c1d509$42386a60$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is from a private thread that probably needs to be taken to the list: Dean Willis wrote: > I would argue that the draft goes outside its applicability statement > anytime it discusses providing privacy. As written, it DOESN'T provide > privacy. It provides a means whereby a user can REQUEST that network > elements NOT PUBLISH additional information that, if published, would > compromise privacy. I believe that "publish", in the context of this > document, means "distribute outside a group of proxies with a shared > administrative policy of mutual trust." > > And I think it is the lack of mutual understanding agreement at this > level that is the holdup. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 26 17:23:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27703 for ; Tue, 26 Mar 2002 17:23:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA15682 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 17:23:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11759; Tue, 26 Mar 2002 17:10:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06881 for ; Tue, 26 Mar 2002 11:34:54 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10152 for ; Tue, 26 Mar 2002 11:34:51 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2QGYsl20732; Tue, 26 Mar 2002 10:34:54 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2QGYrg29184; Tue, 26 Mar 2002 10:34:53 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g2QGYqE05741; Tue, 26 Mar 2002 11:34:52 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 11:34:52 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF8302A5EE6C@eammlnt051.lmc.ericsson.se> From: "Agnieszka Szczurowska (LMC)" To: "'sip@ietf.org'" Cc: "'sip-implementors@cs.columbia.edu'" , "Agnieszka Szczurowska (LMC)" Date: Tue, 26 Mar 2002 11:34:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis 8 translation from "tel" URL to SIP URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I was analyzing draft-ietf-sip-rfc2543bis-08, section 19.1.6 on translation from "tel" URL to SIP URI and I think there might be a missing host in one of the examples. Correct example of simple translation from that section: tel:+358-555-1234567;postd=pp22 equals to sip:+358-555-1234567;postd=pp22@foo.com;user=phone Example of translation in which, I think, the host is missing: tel:+358-555-1234567;postd=pp22;isub=1411 equals to sip:+358-555-1234567;isub=1411;postd=pp22;user=phone Shouldn't the last sip URI be: sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone ? Agnes ---------------------------------------------------------------------------- ----------- Agnieszka Szczurowska * Agnieszka.Szczurowska@lmc.ericsson.se ' ext. 3345 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 26 18:02:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29136 for ; Tue, 26 Mar 2002 18:02:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26180 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 18:02:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22514; Tue, 26 Mar 2002 17:49:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22470 for ; Tue, 26 Mar 2002 17:49:25 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28683 for ; Tue, 26 Mar 2002 17:49:22 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2QMnPl08642; Tue, 26 Mar 2002 16:49:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2QMnPK15830; Tue, 26 Mar 2002 16:49:25 -0600 (CST) Received: from lmf.ericsson.se (rmt160101.am.ericsson.se [138.85.160.101]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA12036; Tue, 26 Mar 2002 16:49:22 -0600 (CST) Message-ID: <3CA0FBC1.E214800B@lmf.ericsson.se> Date: Wed, 27 Mar 2002 00:52:49 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Agnieszka Szczurowska (LMC)" CC: "'sip@ietf.org'" , "'sip-implementors@cs.columbia.edu'" , "Agnieszka Szczurowska (LMC)" Subject: Re: [Sip] bis 8 translation from "tel" URL to SIP URI References: <7B2A7784F4B7F0409947481F3F3FEF8302A5EE6C@eammlnt051.lmc.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, You are right, the host is missing. Gonzalo "Agnieszka Szczurowska (LMC)" wrote: > > Hi, > > I was analyzing draft-ietf-sip-rfc2543bis-08, section 19.1.6 on translation > from "tel" URL to SIP URI and I think there might be a missing host in one > of the examples. > > Correct example of simple translation from that section: > > tel:+358-555-1234567;postd=pp22 equals to > sip:+358-555-1234567;postd=pp22@foo.com;user=phone > > Example of translation in which, I think, the host is missing: > > tel:+358-555-1234567;postd=pp22;isub=1411 equals to > sip:+358-555-1234567;isub=1411;postd=pp22;user=phone > > Shouldn't the last sip URI be: > sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone ? > > Agnes > > ---------------------------------------------------------------------------- > ----------- > Agnieszka Szczurowska > * Agnieszka.Szczurowska@lmc.ericsson.se > ' ext. 3345 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Tue Mar 26 18:04:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29206 for ; Tue, 26 Mar 2002 18:04:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26889 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 18:04:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23265; Tue, 26 Mar 2002 17:52:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23226 for ; Tue, 26 Mar 2002 17:52:10 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28745 for ; Tue, 26 Mar 2002 17:52:07 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2QMpdI6028851; Tue, 26 Mar 2002 14:51:39 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA13675; Tue, 26 Mar 2002 14:51:37 -0800 (PST) Message-ID: <3CA0FB6F.4C75871B@cisco.com> Date: Tue, 26 Mar 2002 17:51:27 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <00d901c1d509$42386a60$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > This is from a private thread that probably needs to be taken to the > list: > > Dean Willis wrote: > > > I would argue that the draft goes outside its applicability statement > > anytime it discusses providing privacy. This seems rather backwards to me. Are you saying that the applicability statement is an exhaustive listing of scope and requirements and anything that is not listed in there can by definiton not be mentioned in the document ? > As written, it DOESN'T provide > > > privacy. It provides a means whereby a user can REQUEST that network > > elements NOT PUBLISH additional information that, if published, would > > compromise privacy. Well, it notes that there are different degrees of privacy and provides procedures for not only hiding this additional information, but also discussion about other headers that need to hidden. It also discusses IP address privacy, which will give you full privacy, however, at your request, the Anonymity header that used to solve this was removed, but the issue is still discussed. > I believe that "publish", in the context of this > > document, means "distribute outside a group of proxies with a shared > > administrative policy of mutual trust." Proxies or User Agents. Also, do not forget the call trace requirement, which was an integral part of the motivation behind this draft (of course per your argument, we now can't support call trace either since that's not part of the applicability statement). > > > > And I think it is the lack of mutual understanding agreement at this > > level that is the holdup. I have no idea what the continued holdup is since there's rarely anything concrete on the table on the mailing list. It would be helpful if we got something from the people that have concerns. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 26 21:15:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03451 for ; Tue, 26 Mar 2002 21:15:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14442 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 21:15:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08336; Tue, 26 Mar 2002 20:49:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08290 for ; Tue, 26 Mar 2002 20:49:26 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02826 for ; Tue, 26 Mar 2002 20:49:24 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2R1mhi04451; Tue, 26 Mar 2002 19:48:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2R1mge27182; Tue, 26 Mar 2002 19:48:42 -0600 (CST) Received: from lmf.ericsson.se (rmt160101.am.ericsson.se [138.85.160.101]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA27110; Tue, 26 Mar 2002 19:48:39 -0600 (CST) Message-ID: <3CA125C5.A0A29BD3@lmf.ericsson.se> Date: Wed, 27 Mar 2002 03:52:05 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: eburger@snowshore.com, "'Rohan Mahy'" , sip@ietf.org, Henning Schulzrinne References: <007501c1cf9c$b2365ec0$13bf3fa6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Thoughts on the reason header field scope Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, After the discussions we had in Minneapolis and in the mailing list, I have thought a little more about the Reason header field. The idea of the Reason header field is to contain "why a particular SIP message has been generated". The Reason header field in responses is easy, because it only applies to 155 responses. About requests, we have several scenarios. 1) A request outside a dialog is sent, and I would like to know why it was sent to me. This is outside the current Reason header field scope, but it is part of the History requirements. However, in order to meet the History requirements more information besides the reason header field is needed. We agreed that such information (like identities) was outside the scope of the Reason draft. 2) A CANCEL or BYE are sent within an INVITE trasaction. The Reason header field would carry, in this scenario, what happended to the INVITE. The INVITE might have been answered with a 200 OK by another branch, or the INVITE may have timed out. 3) Within a dialog, a request is sent because of the result of a previous transaction within the dialog. For instance, a re-INVITE fails, and I send a BYE. Or I send an empty re-INVITE and I do not like the SDP (offer) in the 200 OK. I ACK it (with a correctly formed answer) and I send a BYE. 4) A request is sent and the reason has something to do with the dialog in general, not with any other SIP transaction. For example, no media is being received, or this is just a refresh re-INVITE... 5) Interworking. In this scenario, the reason for sending the request has to do with something that happens outside the dialog. For example, a 3pcc exchanges with me a INVITE-200 OK-ACK putting the media on hold. When the controller tries to contact the other party, it receives a 486 Busy Here. The controller will have to send me a BYE. But if the BYE has a reason field, it is related to something external to the dialog. Points 2, 3 and 4 fall clearly within the scope of the Reason header field. The Reason header field would provide information about the request in relation to something (a request, a transaction or the session associated with the dialog) that is part of the dialog as well. However, 5 is somehow different. It provides information about something that is beyond the UA. One may claim that a 3pcc controller is just another form of a gateway (a SIP to SIP gateway). Note that another "external" reason for sending a BYE may be a user hanging up. The main difference between these external reasons and 2, 3 and 4 is that the latter are typically consequence of protocol operation and the former are triggered by "external" stimulus. Well, these are some thoughts about the scope of the draft. I would appreciate comments on them. I would like to know whether or not people think that we have to include "external" reasons in the draft (right now they are included). Once we have agreed on the scope of the draft, we can discuss the actual format (using Reason values + reason codes as right now, or removing the reason codes). We can also discuss later whether or not it is a good idea to include non-SIP status codes in the draft. Comments/ideas are welcome. Best regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Mar 26 22:21:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05194 for ; Tue, 26 Mar 2002 22:21:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA01024 for sip-archive@odin.ietf.org; Tue, 26 Mar 2002 22:21:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25198; Tue, 26 Mar 2002 21:58:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA25158 for ; Tue, 26 Mar 2002 21:58:44 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05017 for ; Tue, 26 Mar 2002 21:58:37 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2R2w2U16844; Tue, 26 Mar 2002 20:58:02 -0600 From: "Dean Willis" To: "'Flemming Andreasen'" Cc: Subject: RE: [Sip] Comment, SIP Privacy draft Date: Tue, 26 Mar 2002 20:57:37 -0600 Message-ID: <013c01c1d53b$270b8e20$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CA0FB6F.4C75871B@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > > I would argue that the draft goes outside its applicability > > > statement anytime it discusses providing privacy. > > This seems rather backwards to me. Are you saying that the > applicability statement is an exhaustive listing of scope and > requirements and anything that is not listed in there can by > definiton not be mentioned in the document ? Well, I'm suggesting that the draft SHOULD NOT include functionality that is clearly OUTSIDE the scope specified by the applicability statement. That's why we're getting the push back saying the document is inconsistent with the AS. Why should a draft present mechanisms to solve problems for which the draft declares itself "not applicable"? That means either adjust the scope of the draft, or adjust the scope of the AS, as needed and allowed by our "spirit guides" in the IESG . . . > > As written, it DOESN'T provide > > > > > privacy. It provides a means whereby a user can REQUEST > that network > > > elements NOT PUBLISH additional information that, if published, > > > would compromise privacy. > > Well, it notes that there are different degrees of privacy > and provides procedures for not only hiding this additional > information, but also discussion about other headers that > need to hidden. It also discusses IP address privacy, which > will give you full privacy, however, at your request, the > Anonymity header that used to solve this was removed, but the > issue is still discussed. Could I propose we abstract that discussion of privacy concepts into the baseline of a general privacy requirements and definition doc? That would be cool! We need such a doc, and it would help manage the "Scope vs AS" issues on this doc. > > I believe that "publish", in the context of this > > > document, means "distribute outside a group of proxies > with a shared > > > administrative policy of mutual trust." > > Proxies or User Agents. Also, do not forget the call trace > requirement, which was an integral part of the motivation > behind this draft (of course per your argument, we now can't > support call trace either since that's not part of the > applicability statement). Well, that gives us good reason to push back on the AS. OTOH, I bet the security droids would chew on us less if the "sensitive" information were always cryptoprotected, as you propose to do to meet the call-traceback-from-outside-the-trust-domain requirement. > > > > > > And I think it is the lack of mutual understanding > agreement at this > > > level that is the holdup. > > I have no idea what the continued holdup is since there's > rarely anything concrete on the table on the mailing list. It > would be helpful if we got something from the people that > have concerns. Color me "concerned". -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 27 00:42:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08725 for ; Wed, 27 Mar 2002 00:42:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA03251 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 00:42:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26272; Wed, 27 Mar 2002 00:12:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA26240 for ; Wed, 27 Mar 2002 00:12:11 -0500 (EST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08291 for ; Wed, 27 Mar 2002 00:12:10 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 00:11:39 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C39B3F@ftmail> From: "Alan O'Neill" To: Gonzalo Camarillo , "Alan O'Neill" Cc: "'sip@ietf.org '" Subject: RE: [Sip] Manyfolks: Unified local/remote model Date: Wed, 27 Mar 2002 00:11:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org in-line -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: 26 March 2002 17:21 To: Alan O'Neill Cc: 'sip@ietf.org ' Subject: Re: [Sip] Manyfolks: Unified local/remote model Hello Alan, A few clarifications. 1) When you talk about "my design" (which is wrong in your opinion) you are talking about a mechanism that was designed by a bunch of people which did not include myself, and was available in the WG for comments for a long while. The fact that I am the editor now does not make this draft "my design". It is the design of many people. AWO> Sure - the reference was wrt to your role as editor thats all. 2) you claim that I want to "get this out of the door as soon as possible". This is not the first time that folks in the WG complain because we try to meet the deadlines. When we were finishing the SIP spec (bis), folks in the WG also complained... as Jonathan said then, it is unfair that people within the WG, rather than recognizing the incredible amount of work, including evenings, nights and weekends, that we all have put into both bundle 1 and 2, are only complaining about "our" designs. In order to meet the deadlines, we need commited authors and also commited reviewers. The fact that folks wait until the end to throw comments about the whole contents of the draft , is not the author's fault. The manyfolks mechanism has been available for review a long time ago already... and the new additions to manyfolks-04 were discussed in the mailing list a long while before manyfolks-04 was actually released. AWO> Gonzalo..The urgency is clear, understood and appreciated by myself and was why I avoided trying to widen the scope of the work. I have no need or interest to slow this work down. I spotted some serious problems during the previous last call and offered to help write a new draft but non-one contacted me. The 04 version appeared just as I left for a three week round the world trip that included two US visits, a UK visit, a house purchase in Aus, a house sale in the UK, a trip to the IEEE and a lot of air-miles. I responded as soon as I returned to Aus. I can do no more Gonzalo and my responses are made in an attempt to improve this work. 3) You have already mentioned several times the "beauty contest" between e2e and segmented. As far as I know, you are the only one saying that one is better than the other. As I said previously, both have advantages and disadvantages, and the draft does not state that one is better or preferrable than the other. Anyway, if you want me to remove the sentece that troubles you so much (the one that says that the segmented status type does not say anything about the backbone), I can remove it. It is only motivational text, and if you feel so unconfortable with the sentence, I will get rid of it (although I still think that it is a perfectly OK sentence). Let me know how you want me to proceed on this. AWO> Removal would be preferred..thankyou. 4) This draft has been around for a long while, and you are throwing your comments a few days before WGLC is finished (which is alright). Since it seems that many people in the WG are happy with this solution, and what you want is a brand new solution, since the current one is completely useless for your needs, I believe that you should write a contribution (as you suggested) which will be available for everybody in the near future. Due to unfortunate time constrains that don't depend on me, we cannot wait for it before the IESG last call. AWO> I started my review/comments as sson as I could at the begining of last call and they appear to have lasted the length of that last call because we couldn't get down to specifics and assumptions. Your attempts to redirect me out of the SIP wg towards QoS working groups, was not healthy in achieving consensus when I am making informed, if unwelcome comment. The current spec is not ideal but it is certainly not useless. As a stated in my first e-mail I think an excellent job has been done by all in the redesign and rewrite but that there were still issues. The draft scope does not include everything I think is ultimately needed but that is fine and a natural evolution. Things move on and new requirements and bugs become clear over time. But what is in scope and covered should be correct and complete, and support maximum interoperability and utility. Anyway, I believe that we are missunderstanding each other. If you want to discuss any issue related to this mail thread or to this draft, feel free to give me a call to +1 212 939 7171 (New York time zone). We may be able to get a better understanding of the problem on the phone than we have done on the mail so far. If the time difference makes it impossible for you to call me during office hours, let me know in a personal mail and I can try to arrange a conference bridge at a suitable time. AWO> Thanks Gonzalo..I will give you a call to at least reduce some the tension that is evident. I am simply trying to help make a better solution..My comments and our discussion during Last Call will I hope help with that aim. Regards, Alan. Alan O'Neill wrote: > > in-line. > > Gonzalo, > > I'll make this my last one (if you will :-) though given the end of last > call which I think is appropriate to unburden the list. I'll leave future > feedback to a new draft (my only reasonable course) in a while which will > cover more general requirements, the alternative general solution, our > specific longerterm requirements and feature / efficiency comparisons to > manyfolks work. > > Good luck with the IESG, > > Regards, Alan. > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 25 March 2002 18:02 > To: Alan O'Neill > Cc: 'David R. Oran '; 'sip@ietf.org ' > Subject: Re: [Sip] Manyfolks: Unified local/remote model > > Hello, > > The problem with your suggestion is that the offerer specifies what he > will do, not what he wants. > > AWO> No the offer/answer combination says what each will do whilst the > offerer says what it is prepared to do. This is fine since the requirement > is always known and doesn't need to be signalling. "I want 'strength' end to > end QoS please for this session in this direction please." > > For instance, if the offerer says "remote", > it means (in your model) that he will perform resource reservations in > the answerer's access network. But what we really want to say is: I want > QoS in your access network. Do whatever to ensure that. > > AWO> No I say the same thing as you. The offerer is saying I want QoS in > your access network by virtue of setting a precondition. If the answerer > can, it will. If it can't the offerer can try to itself. The offerer saying > remote can lead to four different answerer responses and four different sets > of mechanism by the two endpoints. In eachc ase the response is clear about > whether or not an update is needed. > > You claim that in manyfolks-05 the offerer chooses the status type > (segmented or e2e) and that the answerer cannot change it. This is not a > problem. If I ask for mandatory e2e, I do not want the answerer to > change it to segmented. > > AWO> You don't want the change because of what these mean in your model, not > because of any basic requirement about what we are trying to achieve. The > requirement for preconditions is always e2e (pointless otherwise generally) > so the only thing to resolve is who does what and the resulting > feedback...The strength indicates what we should do if any QoS mech fails.. > > However, if I ask for segmented and I support > e2e, it will be acceptable for me that the status type is changed from > segmented to e2e. Manyfolks-05 already covers this, since the offerer > will include mandatory local/remote and optional e2e (to indicate > support for the e2e status type). The answerer can upgrade the e2e line > to mandatory, and assume that the local/remote preconditions are met > once the e2e preconditions are met. > > AWO> Sure so interoperability is obtained by doubling everything up in the > offer, or by using a subsequent offer. Seems a shame somehow. > > Alan. > > > ---------------------------------------------------------------- > > Notice Regarding Intellectual Property Rights > > > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > > protection on some or all of the technical information submitted by its > > employees in connection with the IETF's standards process. If part(s) of > a > > submission by Flarion is (are) included in a standard and Flarion owns > > patent(s) and/or pending patent application(s) that are essential to > > implementation of such included part(s) in said standard, Flarion is > > prepared to grant a license on fair, reasonable, reciprocal (license back) > > and non-discriminatory terms on such included part(s). > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@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 daemon@ns.ietf.org Wed Mar 27 00:57:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08907 for ; Wed, 27 Mar 2002 00:57:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06652 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 00:57:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01645; Wed, 27 Mar 2002 00:35:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA01610 for ; Wed, 27 Mar 2002 00:35:54 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08624 for ; Wed, 27 Mar 2002 00:35:52 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g2R5Zooq008772; Wed, 27 Mar 2002 06:35:50 +0100 (MET) Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.32]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2R5ZoUD011647; Wed, 27 Mar 2002 07:35:50 +0200 (EET) Message-ID: <3CA15A45.5287C4E5@lmf.ericsson.se> Date: Wed, 27 Mar 2002 07:36:05 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson CC: "'sip@ietf.org'" Subject: Re: [Sip] non-SIP-URI and tag References: <20020326182902.80852.qmail@web11603.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, > Consistency is best. If the URI is not in angle brackets, the > semicolon should mark the end of the URI and the start of the > addr-spec parameters. If we can agree on that, for ANY URI (no matter if the semicolon can be used for other "non-parameter delimiter" purposes within the URI), I am more than happy :) Thanks! Christer Holmberg Ericsson Finland > > > /sean > > --- Christer Holmberg > wrote: > > > > Any comments/clarifications on this? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > "Christer Holmberg (LMF)" wrote: > > > > > Hi, > > > > > > As we have discussed before, if a SIP-URI contains > > URI parameters the URI must be put between brackets. > > Otherwise the parameters will be regarded as header > > parameter (eg the tag parameter). > > > > > > Now, since we are allowed to use other kinds of > > URIs in the To- and From headers (my client may not > > know the specific semantics of those), and the ABNF > > allows those URIs to contain the ";" characters > > (which are used to separate parameters in the > > SIP-URI), does this mean that ALL URIs must be put > > within brackets if they contain the ";" character - > > even if it doesn't have anything to do with URI > > parameters (I assume that is possible)? > > > > > > Otherwise, when my parser finds a ";" character > > when parsing the non-SIP-URI, how does it now if the > > character is simply a character within some part of > > the URI, or if it separates URI parameters, or if it > > separates the URI from the rest of the header? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > _______________________________________________ > > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > ===== > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards� > http://movies.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Mar 27 02:02:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12902 for ; Wed, 27 Mar 2002 02:02:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA21225 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 02:02:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15632; Wed, 27 Mar 2002 01:37:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15585 for ; Wed, 27 Mar 2002 01:37:03 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09521 for ; Wed, 27 Mar 2002 01:37:01 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2R6a0904278; Wed, 27 Mar 2002 01:36:00 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.83.216]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2CW0HWJ; Wed, 27 Mar 2002 01:36:17 -0500 Message-Id: <5.1.0.14.2.20020326223206.00a437f0@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Mar 2002 22:34:41 -0800 To: "Dean Willis" , "'Flemming Andreasen'" From: Matt Holdrege Subject: RE: [Sip] Comment, SIP Privacy draft Cc: In-Reply-To: <013c01c1d53b$270b8e20$bb036e3f@TXDWILLIS2> References: <3CA0FB6F.4C75871B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Furthermore, per the AS this really has nothing to do with Privacy. If this draft is simply to meet the needs of supporting Caller-ID in SIP to PSTN scenarios, you should remove the word "privacy" from the entire draft and replace it with "screening". Then perhaps you can create a separate draft which deals with more pure Internet scenarios for privacy. I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball rolling on that one so we can get it out of the way and work on more interesting stuff. At 06:57 PM 3/26/2002, Dean Willis wrote: > > > > I would argue that the draft goes outside its applicability > > > > statement anytime it discusses providing privacy. > > > > This seems rather backwards to me. Are you saying that the > > applicability statement is an exhaustive listing of scope and > > requirements and anything that is not listed in there can by > > definiton not be mentioned in the document ? > >Well, I'm suggesting that the draft SHOULD NOT include functionality >that is clearly OUTSIDE the scope specified by the applicability >statement. That's why we're getting the push back saying the document is >inconsistent with the AS. Why should a draft present mechanisms to solve >problems for which the draft declares itself "not applicable"? That >means either adjust the scope of the draft, or adjust the scope of the >AS, as needed and allowed by our "spirit guides" in the IESG . . . > > > > As written, it DOESN'T provide > > > > > > > privacy. It provides a means whereby a user can REQUEST > > that network > > > > elements NOT PUBLISH additional information that, if published, > > > > would compromise privacy. > > > > Well, it notes that there are different degrees of privacy > > and provides procedures for not only hiding this additional > > information, but also discussion about other headers that > > need to hidden. It also discusses IP address privacy, which > > will give you full privacy, however, at your request, the > > Anonymity header that used to solve this was removed, but the > > issue is still discussed. > >Could I propose we abstract that discussion of privacy concepts into the >baseline of a general privacy requirements and definition doc? That >would be cool! We need such a doc, and it would help manage the "Scope >vs AS" issues on this doc. > > > > I believe that "publish", in the context of this > > > > document, means "distribute outside a group of proxies > > with a shared > > > > administrative policy of mutual trust." > > > > Proxies or User Agents. Also, do not forget the call trace > > requirement, which was an integral part of the motivation > > behind this draft (of course per your argument, we now can't > > support call trace either since that's not part of the > > applicability statement). > >Well, that gives us good reason to push back on the AS. OTOH, I bet the >security droids would chew on us less if the "sensitive" information >were always cryptoprotected, as you propose to do to meet the >call-traceback-from-outside-the-trust-domain requirement. > > > > > > > > > And I think it is the lack of mutual understanding > > agreement at this > > > > level that is the holdup. > > > > I have no idea what the continued holdup is since there's > > rarely anything concrete on the table on the mailing list. It > > would be helpful if we got something from the people that > > have concerns. > >Color me "concerned". > >-- >Dean > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 05:58:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22148 for ; Wed, 27 Mar 2002 05:57:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA22829 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 05:58:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12741; Wed, 27 Mar 2002 05:17:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12708 for ; Wed, 27 Mar 2002 05:17:43 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21570 for ; Wed, 27 Mar 2002 05:17:36 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RAGgg19048; Wed, 27 Mar 2002 11:16:43 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 10:16:45 -0000 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , "'Flemming Andreasen'" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Wed, 27 Mar 2002 10:16:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D578.7A678622" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D578.7A678622 Content-Type: text/plain I think we should be careful not to confuse 'scope' - what the mechanism actually does/solves - with 'applicability' - environments in which it actually works to provide this. Used within the environment described in the applicability statement, the mechanism *does* provide for a *certain level* of privacy to be maintained whilst also supporting transfer of identity information. This aside, I'd suggest that the broader privacy issue is very urgent. There are many kinds of privacy service, but we can be sure that many of them will require modification of the To/From fields, and so cannot be carried out at a proxy (if you want 2543 compatibility). In the absence of even minimal support for such privacy services to be requested/performed, organisations such as 3GPP are forced into obfuscating the To/From fields & defining proprietary mechanisms for transferring this same information from UE to local proxy. I would suggest that this is a 'bad thing' for SIP. Also, the arguments which lead them to doing this are much more widely applicable than 3GPP networks, so others will be forced down the same path in due course (IMO). We are not going to solve the general privacy problem in time to prevent this kind of messed up handling of To/From, but 3GPP networks at least do fall within the scope of the privacy-04 applicability statement. So, I think we do need something urgently which works within the environments described in the Applicability Statement - whether it is this draft or another one I do not care, as long as it happens soon. What is needed is: a) A way for network entities to assert 'private' identities, in the case that To/From have been obfuscated due to privacy requirements b) A way for users to request that privacy be applied to their identity, whilst also allowing the user to indicate their desired identity to the network A draft which remains within the terms of the Applicability statement could do this. Only 2-3 comments were made *on the list* during WGLC and we have not made much attempt to resolve these. Perhaps those concerned that the draft exceeds the applicability statement could provide detailed comments on the sections they would like modified, or even a modified draft ? Regards, Mark > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 27 March 2002 02:58 > To: 'Flemming Andreasen' > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > > > > > > I would argue that the draft goes outside its applicability > > > > statement anytime it discusses providing privacy. > > > > This seems rather backwards to me. Are you saying that the > > applicability statement is an exhaustive listing of scope and > > requirements and anything that is not listed in there can by > > definiton not be mentioned in the document ? > > Well, I'm suggesting that the draft SHOULD NOT include functionality > that is clearly OUTSIDE the scope specified by the applicability > statement. That's why we're getting the push back saying the > document is > inconsistent with the AS. Why should a draft present > mechanisms to solve > problems for which the draft declares itself "not applicable"? That > means either adjust the scope of the draft, or adjust the scope of the > AS, as needed and allowed by our "spirit guides" in the IESG . . . > > > > As written, it DOESN'T provide > > > > > > > privacy. It provides a means whereby a user can REQUEST > > that network > > > > elements NOT PUBLISH additional information that, if published, > > > > would compromise privacy. > > > > Well, it notes that there are different degrees of privacy > > and provides procedures for not only hiding this additional > > information, but also discussion about other headers that > > need to hidden. It also discusses IP address privacy, which > > will give you full privacy, however, at your request, the > > Anonymity header that used to solve this was removed, but the > > issue is still discussed. > > Could I propose we abstract that discussion of privacy > concepts into the > baseline of a general privacy requirements and definition doc? That > would be cool! We need such a doc, and it would help manage the "Scope > vs AS" issues on this doc. > > > > I believe that "publish", in the context of this > > > > document, means "distribute outside a group of proxies > > with a shared > > > > administrative policy of mutual trust." > > > > Proxies or User Agents. Also, do not forget the call trace > > requirement, which was an integral part of the motivation > > behind this draft (of course per your argument, we now can't > > support call trace either since that's not part of the > > applicability statement). > > Well, that gives us good reason to push back on the AS. OTOH, > I bet the > security droids would chew on us less if the "sensitive" information > were always cryptoprotected, as you propose to do to meet the > call-traceback-from-outside-the-trust-domain requirement. > > > > > > > > > And I think it is the lack of mutual understanding > > agreement at this > > > > level that is the holdup. > > > > I have no idea what the continued holdup is since there's > > rarely anything concrete on the table on the mailing list. It > > would be helpful if we got something from the people that > > have concerns. > > Color me "concerned". > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1D578.7A678622 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Comment, SIP Privacy draft

I think we should be careful not to confuse 'scope' - = what the mechanism actually does/solves - with 'applicability' - = environments in which it actually works to provide this.

Used within the environment described in the = applicability statement, the mechanism *does* provide for a *certain = level* of privacy to be maintained whilst also supporting transfer of = identity information.

This aside, I'd suggest that the broader privacy = issue is very urgent. There are many kinds of privacy service, but we = can be sure that many of them will require modification of the To/From = fields, and so cannot be carried out at a proxy (if you want 2543 = compatibility).

In the absence of even minimal support for such = privacy services to be requested/performed, organisations such as 3GPP = are forced into obfuscating the To/From fields & defining = proprietary mechanisms for transferring this same information from UE = to local proxy. I would suggest that this is a 'bad thing' for SIP. = Also, the arguments which lead them to doing this are much more widely = applicable than 3GPP networks, so others will be forced down the same = path in due course (IMO).

We are not going to solve the general privacy problem = in time to prevent this kind of messed up handling of To/From, but 3GPP = networks at least do fall within the scope of the privacy-04 = applicability statement.

So, I think we do need something urgently which works = within the environments described in the Applicability Statement - = whether it is this draft or another one I do not care, as long as it = happens soon.

What is needed is:
a) A way for network entities to assert 'private' = identities, in the case that To/From have been obfuscated due to = privacy requirements

b) A way for users to request that privacy be applied = to their identity, whilst also allowing the user to indicate their = desired identity to the network

A draft which remains within the terms of the = Applicability statement could do this. Only 2-3 comments were made *on = the list* during WGLC and we have not made much attempt to resolve = these. Perhaps those concerned that the draft exceeds the applicability = statement could provide detailed comments on the sections they would = like modified, or even a modified draft ?

Regards,

Mark





> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.c= om]
> Sent: 27 March 2002 02:58
> To: 'Flemming Andreasen'
> Cc: sip@ietf.org
> Subject: RE: [Sip] Comment, SIP Privacy = draft
>
>
> > > > I would argue that the draft = goes outside its applicability
> > > > statement anytime it discusses = providing privacy.
> >
> > This seems rather backwards to me. Are you = saying that the
> > applicability statement is an exhaustive = listing of scope and
> > requirements and anything that is not = listed in there can by
> > definiton not be mentioned in the document = ?
>
> Well, I'm suggesting that the draft SHOULD NOT = include functionality
> that is clearly OUTSIDE the scope specified by = the applicability
> statement. That's why we're getting the push = back saying the
> document is
> inconsistent with the AS. Why should a draft = present
> mechanisms to solve
> problems for which the draft declares itself = "not applicable"? That
> means either adjust the scope of the draft, or = adjust the scope of the
> AS, as needed and allowed by our "spirit = guides" in the IESG . . .
>
> > > As written, it DOESN'T provide
> > >
> > > > privacy. It provides a means = whereby a user can REQUEST
> > that network
> > > > elements NOT PUBLISH additional = information that, if published,
> > > > would compromise privacy.
> >
> > Well, it notes that there are different = degrees of privacy
> > and provides procedures for not only = hiding this additional
> > information, but also discussion about = other headers that
> > need to hidden. It also discusses IP = address privacy, which
> > will give you full privacy, however, at = your request, the
> > Anonymity header that used to solve this = was removed, but the
> > issue is still discussed.
>
> Could I propose we abstract that discussion of = privacy
> concepts into the
> baseline of a general privacy requirements and = definition doc? That
> would be cool! We need such a doc, and it would = help manage the "Scope
> vs AS" issues on this doc.
>
> > > I believe that "publish", = in the context of this
> > > > document, means "distribute = outside a group of proxies
> > with a shared
> > > > administrative policy of mutual = trust."
> >
> > Proxies or User Agents. Also, do not = forget the call trace
> > requirement, which was an integral part of = the motivation
> > behind this draft (of course per your = argument, we now can't
> > support call trace either since that's not = part of the
> > applicability statement).
>
> Well, that gives us good reason to push back on = the AS. OTOH,
> I bet the
> security droids would chew on us less if the = "sensitive" information
> were always cryptoprotected, as you propose to = do to meet the
> call-traceback-from-outside-the-trust-domain = requirement.
> 
> > > >
> > > > And I think it is the lack of = mutual understanding
> > agreement at this
> > > > level that is the holdup.
> >
> > I have no idea what the continued holdup = is since there's
> > rarely anything concrete on the table on = the mailing list. It
> > would be helpful if we got something from = the people that
> > have concerns.
>
> Color me "concerned".
>
> --
> Dean
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1D578.7A678622-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 06:21:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22414 for ; Wed, 27 Mar 2002 06:21:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28585 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 06:21:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19981; Wed, 27 Mar 2002 05:45:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19938 for ; Wed, 27 Mar 2002 05:45:31 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22020 for ; Wed, 27 Mar 2002 05:45:28 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2RAjU718587 for ; Wed, 27 Mar 2002 05:45:30 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Mar 2002 10:45:29 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439E96B@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Wed, 27 Mar 2002 10:45:28 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org If changing the word privacy to something else really solves the problem, then let us change it. Treatment of calling line identity in the PSTN/ISDN has never used the word privacy in the specifications, but has concentrated simply on the word "restriction". Another word that was being used in the meeting was "verify", and although this one is inherited from the PSTN/ISDN, I think it is possibly also carrying implications of a function being performed that is not. All that is checked in the PSTN/ISDN is that the number is one of an acceptable list, and "screening" is probably a better word to use for that function. However, I suspect that changing terminology is only part of the problem, however I would, like Fleming, appreciate a better understanding of what the problem really is. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Mark Watson[SMTP:mwatson@nortelnetworks.com] > Sent: 27 March 2002 10:16 > To: 'Dean Willis'; 'Flemming Andreasen' > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > > I think we should be careful not to confuse 'scope' - what the mechanism > actually does/solves - with 'applicability' - environments in which it > actually works to provide this. > > Used within the environment described in the applicability statement, the > mechanism *does* provide for a *certain level* of privacy to be maintained > whilst also supporting transfer of identity information. > > This aside, I'd suggest that the broader privacy issue is very urgent. > There are many kinds of privacy service, but we can be sure that many of > them will require modification of the To/From fields, and so cannot be > carried out at a proxy (if you want 2543 compatibility). > > In the absence of even minimal support for such privacy services to be > requested/performed, organisations such as 3GPP are forced into > obfuscating the To/From fields & defining proprietary mechanisms for > transferring this same information from UE to local proxy. I would suggest > that this is a 'bad thing' for SIP. Also, the arguments which lead them to > doing this are much more widely applicable than 3GPP networks, so others > will be forced down the same path in due course (IMO). > > We are not going to solve the general privacy problem in time to prevent > this kind of messed up handling of To/From, but 3GPP networks at least do > fall within the scope of the privacy-04 applicability statement. > > So, I think we do need something urgently which works within the > environments described in the Applicability Statement - whether it is this > draft or another one I do not care, as long as it happens soon. > > What is needed is: > a) A way for network entities to assert 'private' identities, in the case > that To/From have been obfuscated due to privacy requirements > > b) A way for users to request that privacy be applied to their identity, > whilst also allowing the user to indicate their desired identity to the > network > > A draft which remains within the terms of the Applicability statement > could do this. Only 2-3 comments were made *on the list* during WGLC and > we have not made much attempt to resolve these. Perhaps those concerned > that the draft exceeds the applicability statement could provide detailed > comments on the sections they would like modified, or even a modified > draft ? > > Regards, > > Mark > > > > > > > -----Original Message----- > > From: Dean Willis [ mailto:dean.willis@softarmor.com] > > Sent: 27 March 2002 02:58 > > To: 'Flemming Andreasen' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Comment, SIP Privacy draft > > > > > > > > > I would argue that the draft goes outside its applicability > > > > > statement anytime it discusses providing privacy. > > > > > > This seems rather backwards to me. Are you saying that the > > > applicability statement is an exhaustive listing of scope and > > > requirements and anything that is not listed in there can by > > > definiton not be mentioned in the document ? > > > > Well, I'm suggesting that the draft SHOULD NOT include functionality > > that is clearly OUTSIDE the scope specified by the applicability > > statement. That's why we're getting the push back saying the > > document is > > inconsistent with the AS. Why should a draft present > > mechanisms to solve > > problems for which the draft declares itself "not applicable"? That > > means either adjust the scope of the draft, or adjust the scope of the > > AS, as needed and allowed by our "spirit guides" in the IESG . . . > > > > > > As written, it DOESN'T provide > > > > > > > > > privacy. It provides a means whereby a user can REQUEST > > > that network > > > > > elements NOT PUBLISH additional information that, if published, > > > > > would compromise privacy. > > > > > > Well, it notes that there are different degrees of privacy > > > and provides procedures for not only hiding this additional > > > information, but also discussion about other headers that > > > need to hidden. It also discusses IP address privacy, which > > > will give you full privacy, however, at your request, the > > > Anonymity header that used to solve this was removed, but the > > > issue is still discussed. > > > > Could I propose we abstract that discussion of privacy > > concepts into the > > baseline of a general privacy requirements and definition doc? That > > would be cool! We need such a doc, and it would help manage the "Scope > > vs AS" issues on this doc. > > > > > > I believe that "publish", in the context of this > > > > > document, means "distribute outside a group of proxies > > > with a shared > > > > > administrative policy of mutual trust." > > > > > > Proxies or User Agents. Also, do not forget the call trace > > > requirement, which was an integral part of the motivation > > > behind this draft (of course per your argument, we now can't > > > support call trace either since that's not part of the > > > applicability statement). > > > > Well, that gives us good reason to push back on the AS. OTOH, > > I bet the > > security droids would chew on us less if the "sensitive" information > > were always cryptoprotected, as you propose to do to meet the > > call-traceback-from-outside-the-trust-domain requirement. > > > > > > > > > > > > And I think it is the lack of mutual understanding > > > agreement at this > > > > > level that is the holdup. > > > > > > I have no idea what the continued holdup is since there's > > > rarely anything concrete on the table on the mailing list. It > > > would be helpful if we got something from the people that > > > have concerns. > > > > Color me "concerned". > > > > -- > > Dean > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 08:23:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26767 for ; Wed, 27 Mar 2002 08:23:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28112 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 08:23:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18746; Wed, 27 Mar 2002 07:45:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11744 for ; Wed, 27 Mar 2002 07:16:56 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24175; Wed, 27 Mar 2002 07:16:54 -0500 (EST) Message-Id: <200203271216.HAA24175@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 27 Mar 2002 07:16:54 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-manyfolks-resource-06.txt,.ps,.pdf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : Integration of Resource Management and SIP Author(s) : W. Marshall, G. Camarillo, J. Rosenberg Filename : draft-ietf-sip-manyfolks-resource-06.txt,.ps,.pdf Pages : 29 Date : 26-Mar-02 This document defines a generic framework for preconditions which is extensible through IANA registration. This document also discusses how network quality of service can be made a precondition to establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-manyfolks-resource-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020326114641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-manyfolks-resource-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-manyfolks-resource-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020326114641.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 daemon@optimus.ietf.org Wed Mar 27 09:21:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29281 for ; Wed, 27 Mar 2002 09:21:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA13680 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 09:21:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05195; Wed, 27 Mar 2002 08:49:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05152 for ; Wed, 27 Mar 2002 08:49:39 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27701 for ; Wed, 27 Mar 2002 08:49:36 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2RDn7I6017061; Wed, 27 Mar 2002 05:49:07 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA19437; Wed, 27 Mar 2002 05:49:06 -0800 (PST) Message-ID: <3CA1CDC8.A40A9085@cisco.com> Date: Wed, 27 Mar 2002 08:48:56 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <013c01c1d53b$270b8e20$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > > I would argue that the draft goes outside its applicability > > > > statement anytime it discusses providing privacy. > > > > This seems rather backwards to me. Are you saying that the > > applicability statement is an exhaustive listing of scope and > > requirements and anything that is not listed in there can by > > definiton not be mentioned in the document ? > > Well, I'm suggesting that the draft SHOULD NOT include functionality > that is clearly OUTSIDE the scope specified by the applicability > statement. That's why we're getting the push back saying the document is > inconsistent with the AS. Why should a draft present mechanisms to solve > problems for which the draft declares itself "not applicable"? That > means either adjust the scope of the draft, or adjust the scope of the > AS, as needed and allowed by our "spirit guides" in the IESG . . . If the AS is trying to be a complete listing of requirements then it is clearly deficient. Moreover, if this is indeed the intention with an applicability statement, then it is very concerning, that we have this applicability statement being forced into the document by our "spirit guides" at the last minute without any discussion about the actual requirements. As I mentioned before, call trace completely fell through the cracks here essentially rendering the draft useless for what it was supposed to do. As this discussion shows, there is disagreement on other points as well. > > > > > As written, it DOESN'T provide > > > > > > > privacy. It provides a means whereby a user can REQUEST > > that network > > > > elements NOT PUBLISH additional information that, if published, > > > > would compromise privacy. > > > > Well, it notes that there are different degrees of privacy > > and provides procedures for not only hiding this additional > > information, but also discussion about other headers that > > need to hidden. It also discusses IP address privacy, which > > will give you full privacy, however, at your request, the > > Anonymity header that used to solve this was removed, but the > > issue is still discussed. > > Could I propose we abstract that discussion of privacy concepts into the > baseline of a general privacy requirements and definition doc? That > would be cool! We need such a doc, and it would help manage the "Scope > vs AS" issues on this doc. I agree we need a requirements document for the general privacy problem (and perhaps also for this document), but I'm not sure I see how that helps with the document at hand. > > > > I believe that "publish", in the context of this > > > > document, means "distribute outside a group of proxies > > with a shared > > > > administrative policy of mutual trust." > > > > Proxies or User Agents. Also, do not forget the call trace > > requirement, which was an integral part of the motivation > > behind this draft (of course per your argument, we now can't > > support call trace either since that's not part of the > > applicability statement). > > Well, that gives us good reason to push back on the AS. OTOH, I bet the > security droids would chew on us less if the "sensitive" information > were always cryptoprotected, as you propose to do to meet the > call-traceback-from-outside-the-trust-domain requirement. That is already an option described in the document today. However, as noted, it has some unsolved problems. Also, this doesn't address the issue we started discussing, namely how to handle untrusted Remote-Party-Ids. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 09:37:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00043 for ; Wed, 27 Mar 2002 09:37:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA17747 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 09:37:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07371; Wed, 27 Mar 2002 08:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07328 for ; Wed, 27 Mar 2002 08:57:39 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28132 for ; Wed, 27 Mar 2002 08:57:37 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2RDv8K21754; Wed, 27 Mar 2002 05:57:08 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA20961; Wed, 27 Mar 2002 05:57:07 -0800 (PST) Message-ID: <3CA1CFA9.67EDBBD6@cisco.com> Date: Wed, 27 Mar 2002 08:56:57 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Holdrege CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <3CA0FB6F.4C75871B@cisco.com> <5.1.0.14.2.20020326223206.00a437f0@mail.verizon.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Matt Holdrege wrote: > Furthermore, per the AS this really has nothing to do with Privacy. If this > draft is simply to meet the needs of supporting Caller-ID in SIP to PSTN > scenarios, But it is not - what gave you that idea ? > you should remove the word "privacy" from the entire draft and > replace it with "screening". Then perhaps you can create a separate draft > which deals with more pure Internet scenarios for privacy. > > I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball > rolling on that one so we can get it out of the way and work on more > interesting stuff. > I can't believe I'm hearing this. When the DCS group came to the IETF ~3 years ago with this and other extensions, people complained that everything was too PSTN specific and that the idea with SIP was not to replicate the ISUP parameters one by one. I thought it was good feedback then, and I still think it is. However, we are now going full circle, and you want to start replicating the ISUP parameters and only think about SIP-PSTN interworking. I still have higher hopes than that. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 09:38:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00102 for ; Wed, 27 Mar 2002 09:38:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA18073 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 09:38:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08365; Wed, 27 Mar 2002 09:01:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08324 for ; Wed, 27 Mar 2002 09:01:20 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28323 for ; Wed, 27 Mar 2002 09:01:17 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2RE0mY05928; Wed, 27 Mar 2002 06:00:48 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA21779; Wed, 27 Mar 2002 06:00:48 -0800 (PST) Message-ID: <3CA1D086.42AC035@cisco.com> Date: Wed, 27 Mar 2002 09:00:38 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > > > I think we should be careful not to confuse 'scope' - what the > mechanism actually does/solves - with 'applicability' - environments > in which it actually works to provide this. > Yes, yes, and yes. > > What is needed is: > a) A way for network entities to assert 'private' identities, in the > case that To/From have been obfuscated due to privacy requirements > > b) A way for users to request that privacy be applied to their > identity, whilst also allowing the user to indicate their desired > identity to the network > And c) Enable call trace d) Not require all "networks" to trust one another -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 12:05:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08618 for ; Wed, 27 Mar 2002 12:05:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28615 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 12:05:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23113; Wed, 27 Mar 2002 11:47:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23078 for ; Wed, 27 Mar 2002 11:47:39 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07310 for ; Wed, 27 Mar 2002 11:47:37 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:46:58 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Mar 2002 08:47:09 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:47:09 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 08:47:08 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 27 Mar 2002 08:43:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Comment, SIP Privacy draft Date: Wed, 27 Mar 2002 08:43:53 -0800 Message-ID: Thread-Topic: [Sip] Comment, SIP Privacy draft thread-index: AcHVl4m9f4rTDDVNRYihDa9us5mI7AAFvwUA From: "Christian Huitema" To: "Flemming Andreasen" , "Mark Watson" Cc: "Dean Willis" , X-OriginalArrivalTime: 27 Mar 2002 16:43:53.0812 (UTC) FILETIME=[94A79140:01C1D5AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23080 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > I think we should be careful not to confuse 'scope' - what the > > mechanism actually does/solves - with 'applicability' - environments > > in which it actually works to provide this. > > > > Yes, yes, and yes. This should give us a first point of consensus. The draft is about providing caller identification, which generally leads to compromising the caller privacy -- you are definitely less private if the network identifies you that if it does not. Naming such a draft a "privacy draft" is Orwellian newspeak. So, let's call it "caller-identification draft" and resolve at least the name part issue. > > What is needed is: > > a) A way for network entities to assert 'private' identities, in the > > case that To/From have been obfuscated due to privacy requirements > > > > b) A way for users to request that privacy be applied to their > > identity, whilst also allowing the user to indicate their desired > > identity to the network Yes, let's work on an actual privacy draft. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 12:09:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08838 for ; Wed, 27 Mar 2002 12:09:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29692 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 12:09:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23723; Wed, 27 Mar 2002 11:49:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23684 for ; Wed, 27 Mar 2002 11:49:26 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07384 for ; Wed, 27 Mar 2002 11:49:24 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2RGmtK22986; Wed, 27 Mar 2002 11:48:56 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA28571; Wed, 27 Mar 2002 10:48:54 -0600 (CST) Message-ID: <3CA1F7F5.8070508@lucent.com> Date: Wed, 27 Mar 2002 10:48:53 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip Subject: Re: [Sip] Thoughts on the reason header field scope References: <007501c1cf9c$b2365ec0$13bf3fa6@cisco.com> <3CA125C5.A0A29BD3@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hello, > > After the discussions we had in Minneapolis and in the mailing list, I > have thought a little more about the Reason header field. Gonzalo: Some comments. > The idea of the Reason header field is to contain "why a particular SIP > message has been generated". > > The Reason header field in responses is easy, because it only applies to > 155 responses. The I-D currently says that the header is a general header; i.e. it can appear in any request and any response. I think that the header makes most sense as a request header only (with the exception of 155). There are already elaborate response codes in SIP; why add one more way of propagating responses. 155 is a special provisional response which elicits a further request (UPDATE), so the Reason header does add some value to a generic 155 response. I think that The I-D should state that 155 is the only response to which the Reason header can be applied to. > 1) A request outside a dialog is sent, and I would like to know why it > was sent to me. This is outside the current Reason header field scope, > but it is part of the History requirements. Does this mean that the Reason header cannot be used in a request that establishes a dialog (like the initial INVITE to a UAS)? I did not get that impression from the I-D. If that is indeed the case, then aren't we limiting the header artifically? > 5) Interworking. In this scenario, the reason for sending the request > has to do with something that happens outside the dialog. For example, a > 3pcc exchanges with me a INVITE-200 OK-ACK putting the media on hold. > When the controller tries to contact the other party, it receives a 486 > Busy Here. The controller will have to send me a BYE. But if the BYE > has a reason field, it is related to something external to the dialog. > > Points 2, 3 and 4 fall clearly within the scope of the Reason header > field. [...] > However, 5 is somehow different. It provides information about something > that is beyond the UA. One may claim that a 3pcc controller is just > another form of a gateway (a SIP to SIP gateway). > > Note that another "external" reason for sending a BYE may be a user > hanging up. The main difference between these external reasons and 2, 3 > and 4 is that the latter are typically consequence of protocol operation > and the former are triggered by "external" stimulus. This may be splitting hairs, really. Regardless of if a BYE was triggered by an external stimuli, the fact that a UAS gets a BYE, understands it and processes it makes the BYE a consequence of the protocol operation. > Well, these are some thoughts about the scope of the draft. I would > appreciate comments on them. I would like to know whether or not people > think that we have to include "external" reasons in the draft (right now > they are included). I think we should (within reason [no pun intended] of course -- and that will be the hardest part). Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 12:17:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09410 for ; Wed, 27 Mar 2002 12:17:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01810 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 12:17:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19717; Wed, 27 Mar 2002 11:37:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19664 for ; Wed, 27 Mar 2002 11:37:02 -0500 (EST) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06365 for ; Wed, 27 Mar 2002 11:36:53 -0500 (EST) From: ysong@telcordia.com Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA02923 for ; Wed, 27 Mar 2002 11:31:17 -0500 (EST) Subject: [Sip] question on NOTIFY To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 27 Mar 2002 11:31:21 -0500 X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at 03/27/2002 11:31:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have questions on the NOTIFY usage when subscriptions are provisioned on SIP UAs via means other than using SUBSCRIBE. Suppose the notifier and the subscriber (SIP user) are provisioned with static dialog ID and Event information. Suppose there is a state change, so the notifier sends a NOTIFY with the dialog ID and Event header, and the request-URI containing the SIP URL of the user. The NOTIFY is eventually sent to the user's domain proxy server which realizes that the user is registered at three UAs. In this case, would the proxy server fork NOTIFY to three UAs and apply the same response processing as normal (like INVITE forking)? If the proxy server record-routes the NOTIFY, the notifer will not honor it because NOTIFY is not dialog creating method. Also, if the UAs put Contact in 200 response to NOTIFY, the notifier will not honor the contact address because NOTIFY is not a target refreshing method. Is this understanding correct? Any comments on this mechanism? Thanks, YoungSun _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 13:43:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15363 for ; Wed, 27 Mar 2002 13:43:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29940 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 13:43:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27231; Wed, 27 Mar 2002 13:25:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27062 for ; Wed, 27 Mar 2002 13:24:49 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10222 for ; Wed, 27 Mar 2002 12:34:35 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2RHXXE04742; Wed, 27 Mar 2002 12:33:33 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.83.216]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2CW0NG2; Wed, 27 Mar 2002 12:33:49 -0500 Message-Id: <5.1.0.14.2.20020327092746.02b14920@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Mar 2002 09:31:07 -0800 To: Flemming Andreasen From: Matt Holdrege Subject: Re: [Sip] Comment, SIP Privacy draft Cc: Dean Willis , sip@ietf.org In-Reply-To: <3CA1CFA9.67EDBBD6@cisco.com> References: <3CA0FB6F.4C75871B@cisco.com> <5.1.0.14.2.20020326223206.00a437f0@mail.verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 05:56 AM 3/27/2002, Flemming Andreasen wrote: >Matt Holdrege wrote: > > > Furthermore, per the AS this really has nothing to do with Privacy. If this > > draft is simply to meet the needs of supporting Caller-ID in SIP to PSTN > > scenarios, > >But it is not - what gave you that idea ? The AS. And the way the draft is being applied in other groups. > > you should remove the word "privacy" from the entire draft and > > replace it with "screening". Then perhaps you can create a separate draft > > which deals with more pure Internet scenarios for privacy. > > > > I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball > > rolling on that one so we can get it out of the way and work on more > > interesting stuff. > > > >I can't believe I'm hearing this. When the DCS group came to the IETF ~3 years >ago with this and other extensions, people complained that everything was too >PSTN specific and that the idea with SIP was not to replicate the ISUP >parameters one by one. I thought it was good feedback then, and I still think >it is. However, we are now going full circle, and you want to start >replicating >the ISUP parameters and only think about SIP-PSTN interworking. I still have >higher hopes than that. Re-read the above where I say let's get caller-id out of the way to work on the more interesting stuff. The fact is that we need SIP to PSTN interworking. If you are not interested in that, fine. You can work on the more general case and I fully support that. But some of us still care about interworking with the PSTN and we need to get that bit specified ASAP before the world is polluted with proprietary SIP headers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 14:37:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18378 for ; Wed, 27 Mar 2002 14:37:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04441 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 14:37:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02190; Wed, 27 Mar 2002 14:07:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02156 for ; Wed, 27 Mar 2002 14:07:17 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16790 for ; Wed, 27 Mar 2002 14:07:16 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2RJ6bI13131; Wed, 27 Mar 2002 11:06:37 -0800 (PST) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACT19110; Wed, 27 Mar 2002 11:06:46 -0800 (PST) Date: Wed, 27 Mar 2002 11:04:17 -0800 (Pacific Standard Time) From: Rohan Mahy To: Alan Johnston cc: "'Kim Liu'" , Subject: RE: [Sip] Quick requestion about REFER+Replaces: examples In-Reply-To: <000201c1d1e0$368b8fc0$c18c4041@ajohnston> Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, the "-" in to-tag and from-tag is unreserved and therefore doesn't need to be escaped. technically we could have allowed "@" in hnv-unreserved without making implementation of new parsers terribly difficult, but that is water under the bridge now. thanks, -rohan On Fri, 22 Mar 2002, Alan Johnston wrote: > Hi Kim, > > You are right. The lack of escaping makes the examples in these drafts > more readable but perhaps less accurate per the syntax. > > Take a look at the SIP Service Examples draft > (http://search.ietf.org/internet-drafts/draft-ietf-sipping-service-examp > les-00.txt) that show the escaping of the Replaces header in Refer-To > headers. > > Thanks, > Alan Johnston > WorldCom > sip:alan@siptest.wcom.com > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > > Behalf Of Kim Liu > > Sent: Friday, March 22, 2002 1:18 PM > > To: sip@ietf.org > > Subject: [Sip] Quick requestion about REFER+Replaces: examples > > > > > > In draft-ietf-sip-refer-02.txt and > > draft-bhatia-3pcc-refer-01.txt there > > are several examples presented with the Replaces header in a URL as: > > > > Refer-To: > > sip:dave@denver.com?Replaces:12345%40192.168.118.3;to-tag=1234 > > 5;from-tag=5FFE-3994; > > > > Just to double check my understanding of the URL header parsing, > > shouldn't all of those be more or less: > > > > Refer-To: > > sip:dave@denver.com?Replaces=12345%40192.168.118.3%3bto%2dtag% > > 3d12345%3bfrom%2dtag%3d5FFE%2d3994; > > > > Just trying to make sure I haven't missed exactly where the > > to-tag and > > from-tag belongs in this case. > > > > -- > > Kim Liu kliu@lucent.com : Everyone is a darn fool for at > > Senior Software Engineer : least five minutes a day; > > Lucent Technologies : wisdom consists of not > > Clearwater, FL, 33761 : exceeding the limit > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:16:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20096 for ; Wed, 27 Mar 2002 15:16:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA06994 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:16:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05158; Wed, 27 Mar 2002 14:54:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05126 for ; Wed, 27 Mar 2002 14:54:01 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19019 for ; Wed, 27 Mar 2002 14:53:59 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2RJrUI6009763; Wed, 27 Mar 2002 11:53:30 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA27896; Wed, 27 Mar 2002 11:53:28 -0800 (PST) Message-ID: <3CA2232F.637520EE@cisco.com> Date: Wed, 27 Mar 2002 14:53:19 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Mark Watson , Dean Willis , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > > I think we should be careful not to confuse 'scope' - what the > > > mechanism actually does/solves - with 'applicability' - environments > > > in which it actually works to provide this. > > > > > > > Yes, yes, and yes. > > This should give us a first point of consensus. The draft is about > providing caller identification, which generally leads to compromising > the caller privacy -- you are definitely less private if the network > identifies you that if it does not. Naming such a draft a "privacy > draft" is Orwellian newspeak. So, let's call it "caller-identification > draft" and resolve at least the name part issue. > OK, but it still needs to address "privacy" for such caller-id and enable call trace. > > > > What is needed is: > > > a) A way for network entities to assert 'private' identities, in the > > > case that To/From have been obfuscated due to privacy requirements > > > > > > b) A way for users to request that privacy be applied to their > > > identity, whilst also allowing the user to indicate their desired > > > identity to the network > > Yes, let's work on an actual privacy draft. Are you thereby suggesting that the "caller-id" draft should not address any kind of privacy beyond the Remote-Party-Id (e.g. inserting "anonymous@localhost" in the From header field) and hence not be concerned with a more general privacy solution ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:19:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20540 for ; Wed, 27 Mar 2002 15:19:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07096 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:19:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05621; Wed, 27 Mar 2002 14:58:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05590 for ; Wed, 27 Mar 2002 14:58:41 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19210 for ; Wed, 27 Mar 2002 14:58:40 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2RJwBI6012605; Wed, 27 Mar 2002 11:58:11 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA05143; Wed, 27 Mar 2002 11:58:09 -0800 (PST) Message-ID: <3CA22446.1642889E@cisco.com> Date: Wed, 27 Mar 2002 14:57:58 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Holdrege CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <3CA0FB6F.4C75871B@cisco.com> <5.1.0.14.2.20020326223206.00a437f0@mail.verizon.net> <5.1.0.14.2.20020327092746.02b14920@mail.verizon.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Matt Holdrege wrote: > Re-read the above where I say let's get caller-id out of the way to work on > the more interesting stuff. The fact is that we need SIP to PSTN > interworking. If you are not interested in that, fine. That's hardly what I said. > You can work on the > more general case and I fully support that. But some of us still care about > interworking with the PSTN and we need to get that bit specified ASAP > before the world is polluted with proprietary SIP headers. If that's all you want it's pretty easy: Just add an ISUP body to all your SIP messages and fill in the blanks. However some of us were hoping for something a little more general and useful. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:20:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20601 for ; Wed, 27 Mar 2002 15:20:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07127 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:20:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05483; Wed, 27 Mar 2002 14:56:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05450 for ; Wed, 27 Mar 2002 14:56:54 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19135 for ; Wed, 27 Mar 2002 14:56:52 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2RJuNS16943; Wed, 27 Mar 2002 14:56:23 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA05981; Wed, 27 Mar 2002 13:56:22 -0600 (CST) Message-ID: <3CA223E4.7020707@lucent.com> Date: Wed, 27 Mar 2002 13:56:20 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Sean Olson CC: Gonzalo Camarillo , sip Subject: Re: [Sip] Thoughts on the reason header field scope References: <20020327192458.71443.qmail@web11601.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: >>There >>are already elaborate response codes in SIP; why add >>one more way of >>propagating responses. 155 is a special provisional >>response which >>elicits a further request (UPDATE), so the Reason >>header does add some >>value to a generic 155 response. I think that The >>I-D should state that >>155 is the only response to which the Reason header >>can be applied to. >> > > Would a Reason: header be allowed in a 183? I don't speak for the authors of course, but my feeling is that 183 as a response code is associated with QoS preconditions. It has a well defined profile, so to speak. So carrying a Reason phrase in it probably does not add too much. 155 on the other hand is a response code for solving the early media, HERFP, as well as repairable error responses. So there is some good to further qualifying the 155 response for the UAC. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:31:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21204 for ; Wed, 27 Mar 2002 15:31:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA08153 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:31:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06680; Wed, 27 Mar 2002 15:10:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06649 for ; Wed, 27 Mar 2002 15:10:16 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19788 for ; Wed, 27 Mar 2002 15:10:14 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2RK97B21552; Wed, 27 Mar 2002 15:09:07 -0500 (EST) Received: from matt.verizon.net (MATT [10.128.83.216]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G2CW0PC4; Wed, 27 Mar 2002 15:09:24 -0500 Message-Id: <5.1.0.14.2.20020327120551.00a4f180@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Mar 2002 12:08:45 -0800 To: Flemming Andreasen From: Matt Holdrege Subject: Re: [Sip] Comment, SIP Privacy draft Cc: Dean Willis , sip@ietf.org In-Reply-To: <3CA22446.1642889E@cisco.com> References: <3CA0FB6F.4C75871B@cisco.com> <5.1.0.14.2.20020326223206.00a437f0@mail.verizon.net> <5.1.0.14.2.20020327092746.02b14920@mail.verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 11:57 AM 3/27/2002, Flemming Andreasen wrote: >M > > You can work on the > > more general case and I fully support that. But some of us still care about > > interworking with the PSTN and we need to get that bit specified ASAP > > before the world is polluted with proprietary SIP headers. > >If that's all you want it's pretty easy: Just add an ISUP body to all >your SIP >messages and fill in the blanks. However some of us were hoping for >something a >little more general and useful. No, we actually need the Remote Party ID and restricted flag. I also hope for a more general and useful way to deal with privacy. But it seems like that's going to be a difficult sell or at least a longer term project than originally expected. So it would be nice to get something less out the door now so that Service Providers can use it today, and the ITU-T and 3GPP won't go off and do something to the SIP headers that the IETF doesn't support. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:39:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21657 for ; Wed, 27 Mar 2002 15:39:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09068 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:39:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06869; Wed, 27 Mar 2002 15:14:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06838 for ; Wed, 27 Mar 2002 15:14:31 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19928 for ; Wed, 27 Mar 2002 15:14:29 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RKDxI01536 for ; Wed, 27 Mar 2002 15:14:00 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 15:14:01 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A1E8@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Vijay K. Gurbani'" , Sean Olson Cc: Gonzalo Camarillo , sip Subject: RE: [Sip] Thoughts on the reason header field scope Date: Wed, 27 Mar 2002 15:13:50 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 183 responses are a key element of early media too. It might not hurt to have a way to indicate why one of these has been generated. -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@lucent.com] Sent: Wednesday, March 27, 2002 2:56 PM To: Sean Olson Cc: Gonzalo Camarillo; sip Subject: Re: [Sip] Thoughts on the reason header field scope Sean Olson wrote: >>There >>are already elaborate response codes in SIP; why add >>one more way of >>propagating responses. 155 is a special provisional >>response which >>elicits a further request (UPDATE), so the Reason >>header does add some >>value to a generic 155 response. I think that The >>I-D should state that >>155 is the only response to which the Reason header >>can be applied to. >> > > Would a Reason: header be allowed in a 183? I don't speak for the authors of course, but my feeling is that 183 as a response code is associated with QoS preconditions. It has a well defined profile, so to speak. So carrying a Reason phrase in it probably does not add too much. 155 on the other hand is a response code for solving the early media, HERFP, as well as repairable error responses. So there is some good to further qualifying the 155 response for the UAC. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 15:40:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21695 for ; Wed, 27 Mar 2002 15:40:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09105 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 15:40:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03320; Wed, 27 Mar 2002 14:25:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA03289 for ; Wed, 27 Mar 2002 14:24:59 -0500 (EST) Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17670 for ; Wed, 27 Mar 2002 14:24:57 -0500 (EST) Message-ID: <20020327192458.71443.qmail@web11601.mail.yahoo.com> Received: from [131.107.3.83] by web11601.mail.yahoo.com via HTTP; Wed, 27 Mar 2002 11:24:58 PST Date: Wed, 27 Mar 2002 11:24:58 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Thoughts on the reason header field scope To: "Vijay K. Gurbani" , Gonzalo Camarillo Cc: sip In-Reply-To: <3CA1F7F5.8070508@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > There > are already elaborate response codes in SIP; why add > one more way of > propagating responses. 155 is a special provisional > response which > elicits a further request (UPDATE), so the Reason > header does add some > value to a generic 155 response. I think that The > I-D should state that > 155 is the only response to which the Reason header > can be applied to. Would a Reason: header be allowed in a 183? /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 16:53:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26185 for ; Wed, 27 Mar 2002 16:53:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16247 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 16:54:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13565; Wed, 27 Mar 2002 16:19:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13528 for ; Wed, 27 Mar 2002 16:19:18 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24088 for ; Wed, 27 Mar 2002 16:19:15 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 13:18:46 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Mar 2002 13:18:46 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 27 Mar 2002 13:18:45 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Mar 2002 13:18:45 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 27 Mar 2002 13:15:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] Comment, SIP Privacy draft Date: Wed, 27 Mar 2002 13:15:19 -0800 Message-ID: Thread-Topic: [Sip] Comment, SIP Privacy draft thread-index: AcHVyMESvE3zqAy+RjWQfIVxArjxPwAC9ZLw From: "Christian Huitema" To: "Flemming Andreasen" Cc: "Mark Watson" , "Dean Willis" , X-OriginalArrivalTime: 27 Mar 2002 21:15:21.0855 (UTC) FILETIME=[8115B0F0:01C1D5D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA13529 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > > > > > > What is needed is: > > > > a) A way for network entities to assert 'private' identities, in the > > > > case that To/From have been obfuscated due to privacy requirements > > > > > > > > b) A way for users to request that privacy be applied to their > > > > identity, whilst also allowing the user to indicate their desired > > > > identity to the network > > > > Yes, let's work on an actual privacy draft. > > Are you thereby suggesting that the "caller-id" draft should not address > any > kind of privacy beyond the Remote-Party-Id (e.g. inserting > "anonymous@localhost" in the From header field) and hence not be concerned > with a more general privacy solution ? Yes. We should have a separate caller-id/remote-party-id draft, which is a tactical solution for some types of networks, and a generic privacy draft, that looks at how to actually provide reasonable privacy across the whole chain, without assuming a "public telephony server" in the middle. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Mar 27 17:44:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28316 for ; Wed, 27 Mar 2002 17:44:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21877 for sip-archive@odin.ietf.org; Wed, 27 Mar 2002 17:44:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19465; Wed, 27 Mar 2002 17:20:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19438 for ; Wed, 27 Mar 2002 17:20:16 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27251 for ; Wed, 27 Mar 2002 17:20:13 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D78D71E164 for ; Wed, 27 Mar 2002 17:20:15 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA04886; Wed, 27 Mar 2002 17:20:12 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA71243; Wed, 27 Mar 2002 17:18:57 -0500 (EST) Date: Wed, 27 Mar 2002 17:18:57 -0500 (EST) Message-Id: <200203272218.RAA71243@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In all the criticism and discussion of draft-ietf-sip-privacy, there has been one fact conveniently overlooked - the facilities already in bis-09. I find them scary. When a UAC sends an INVITE and is challenged by a proxy, and responds with the authentication credentials, the proxy has ascertained the identity of the UAC. The proxy can then add a "Call-Info" header to the INVITE that contains whatever identity information it wants. See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element." How? No clue is given. Note that with "Call-Info" headers can appear in both requests and responses, and may be used by the UAC/UAS for presentation, there are *no* restrictions on what this information could be, *no* restrictions on how far it is propagated, *no* requirement that it be encrypted, and *no* mechanism for the UAC/UAS to request that this not be done. In that sense, draft-ietf-sip-privacy *really* is about privacy. It includes a mechanism whereby the UAC can request that its identity be kept private and that proxies NOT include information (which the proxies will obtain and know) in the message that is forwarded to the destination. The entire rest of the draft deals with the consequences of this request. I find it very surprising that an attempt to restrict the use of the Call-Info header (thereby requiring a new header name, Remote-Party-ID) is meeting with such objection, when there was absolutely no comment on the Call-Info usage (and no applicability statement attached to it) during the WGLC or AD review of 2543bis. From a service provider point of view, I'm not sure I see a difference between requiring certain proxy behavior with respect to the "Call-Info" headers, than requiring the same proxy behavior with "Remote-Party-ID" headers. Codifing the requirements would be useful in either case; and doing this with purchase orders is likely not the best way to do this. However, I do believe Remote-Party-ID is more general than Call-Info, and solves a bigger piece of the problem. While sufficient mechanism exists in bis-09 to do CLIP/CLIR through the use of Call-Info headers, it is without the ability of the UAC/UAS to know that its anonymity request will be honored (presumably signaled through use of "Anonymous" in the display-name of the From header). Better trust that proxy when you send the Authorization information. Bill Marshall wtm@research.att.com -----original message----- Date: Wed, 27 Mar 2002 12:08:45 -0800 To: Flemming Andreasen From: Matt Holdrege Subject: Re: [Sip] Comment, SIP Privacy draft Cc: Dean Willis , sip@ietf.org At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > Matt Holdrege wrote: > > You can work on the > > more general case and I fully support that. But some of us still care about > > interworking with the PSTN and we need to get that bit specified ASAP > > before the world is polluted with proprietary SIP headers. > >If that's all you want it's pretty easy: Just add an ISUP body to all >your SIP >messages and fill in the blanks. However some of us were hoping for >something a >little more general and useful. No, we actually need the Remote Party ID and restricted flag. I also hope for a more general and useful way to deal with privacy. But it seems like that's going to be a difficult sell or at least a longer term project than originally expected. So it would be nice to get something less out the door now so that Service Providers can use it today, and the ITU-T and 3GPP won't go off and do something to the SIP headers that the IETF doesn't support. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 05:47:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20820 for ; Thu, 28 Mar 2002 05:47:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA08484 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 05:47:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07428; Thu, 28 Mar 2002 05:27:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07384 for ; Thu, 28 Mar 2002 05:27:03 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20626 for ; Thu, 28 Mar 2002 05:26:59 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2SAQ3g06543; Thu, 28 Mar 2002 11:26:03 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2SAPRh01676; Thu, 28 Mar 2002 10:25:28 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 10:26:04 -0000 Message-ID: From: "Mark Watson" To: "'Christian Huitema'" , Flemming Andreasen Cc: Dean Willis , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Thu, 28 Mar 2002 10:25:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D642.F2BABA16" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D642.F2BABA16 Content-Type: text/plain > > > > > What is needed is: > > > > > a) A way for network entities to assert 'private' > identities, in > the > > > > > case that To/From have been obfuscated due to privacy > requirements > > > > > > > > > > b) A way for users to request that privacy be applied to their > > > > > identity, whilst also allowing the user to indicate their > desired > > > > > identity to the network > > > > > > Yes, let's work on an actual privacy draft. > > > > Are you thereby suggesting that the "caller-id" draft should not > address > > any > > kind of privacy beyond the Remote-Party-Id (e.g. inserting > > "anonymous@localhost" in the From header field) and hence not be > concerned > > with a more general privacy solution ? > > Yes. We should have a separate caller-id/remote-party-id > draft, which is > a tactical solution for some types of networks, and a generic privacy > draft, that looks at how to actually provide reasonable privacy across > the whole chain, without assuming a "public telephony server" in the > middle. I absolutely agree on the need for the generic privacy draft - and I think this is quite urgent. If you restrict the other part to identity-assertion between trusted entities, and remove privacy indications altogether, you then have to assume that these identities are 'private' i.e. cannot be passed outside the trusted network. This doesn't work well when interworking with the PSTN - I could check the identity in the From field, and if it is a tel URL which matches the network asserted identity, I'd know I would mark this as 'available' in the PSTN, but this matching is not very clean. Plus a UA which has a telephone number *and* a normal SIP URI will put the latter in the From. In my view you just can't separate identity assertion and privacy - trying to do this with From and To was a big mistake in the first place. If we define a *basic* identity assertion mechanism for the trusted network case it should include *basic* 'restriction status' too, and a means for the UA to indicate this, if it knows. The reference to "Public telephony server" above is very misplaced. 3GPP & DCS SIP networks are not telephony networks. We need less of this invective and more focus on the real problems. We should be aware that if we take the above approach we still have the following problem: UAs cannot include information in the existing SIP headers which (a) they know to be subject to privacy restrictions *and* (b) needs to be processed by the network. This is because they have no way of indicating that the data has this privacy status. So, people will still try to invent new headers to effectively replace the From field, which I think everyone agrees is a bad thing, and perhaps exactly what we are trying to avoid. A possible solution, as mentioned in the WGLC comments, would be to define a way for the UA to indicate the privacy status of existing headers as well (if it knows!). ...Mark ------_=_NextPart_001_01C1D642.F2BABA16 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Comment, SIP Privacy draft

> > > > > What is needed is:
> > > > > a) A way for network = entities to assert 'private'
> identities, in
> the
> > > > > case that To/From have been = obfuscated due to privacy
> requirements
> > > > >
> > > > > b) A way for users to = request that privacy be applied to their
> > > > > identity, whilst also = allowing the user to indicate their
> desired
> > > > > identity to the = network
> > >
> > > Yes, let's work on an actual privacy = draft.
> >
> > Are you thereby suggesting that the = "caller-id" draft should not
> address
> > any
> > kind of privacy beyond the Remote-Party-Id = (e.g. inserting
> > "anonymous@localhost" in the = From header field) and hence not be
> concerned
> > with a more general privacy solution = ?
>
> Yes. We should have a separate = caller-id/remote-party-id
> draft, which is
> a tactical solution for some types of networks, = and a generic privacy
> draft, that looks at how to actually provide = reasonable privacy across
> the whole chain, without assuming a = "public telephony server" in the
> middle.

I absolutely agree on the need for the generic = privacy draft - and I think this is quite urgent.

If you restrict the other part to identity-assertion = between trusted entities, and remove privacy indications altogether, = you then have to assume that these identities are 'private' i.e. cannot = be passed outside the trusted network. This doesn't work well when = interworking with the PSTN - I could check the identity in the From = field, and if it is a tel URL which matches the network asserted = identity, I'd know I would mark this as 'available' in the PSTN, but = this matching is not very clean. Plus a UA which has a telephone number = *and* a normal SIP URI will put the latter in the From.

In my view you just can't separate identity assertion = and privacy - trying to do this with From and To was a big mistake in = the first place. If we define a *basic* identity assertion mechanism = for the trusted network case it should include *basic* 'restriction = status' too, and a means for the UA to indicate this, if it = knows.

The reference to "Public telephony server" = above is very misplaced. 3GPP & DCS SIP networks are not telephony = networks. We need less of this invective and more focus on the real = problems.

We should be aware that if we take the above approach = we still have the following problem:

UAs cannot include information in the existing SIP = headers which (a) they know to be subject to privacy restrictions *and* = (b) needs to be processed by the network. This is because they have no = way of indicating that the data has this privacy status.

So, people will still try to invent new headers to = effectively replace the From field, which I think everyone agrees is a = bad thing, and perhaps exactly what we are trying to avoid.

A possible solution, as mentioned in the WGLC = comments, would be to define a way for the UA to indicate the privacy = status of existing headers as well (if it knows!).

...Mark

------_=_NextPart_001_01C1D642.F2BABA16-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 08:41:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25258 for ; Thu, 28 Mar 2002 08:41:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16757 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 08:41:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15464; Thu, 28 Mar 2002 08:14:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15433 for ; Thu, 28 Mar 2002 08:14:09 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24296 for ; Thu, 28 Mar 2002 08:14:06 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id IAA20177; Thu, 28 Mar 2002 08:13:19 -0500 (EST) Subject: Re: [Sip] Comment, SIP Privacy draft To: William Marshall Cc: sip@ietf.org Date: Thu, 28 Mar 2002 08:13:18 -0500 Message-ID: X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 03/28/2002 08:13:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org William Marshall wrote: >Better trust that proxy when you send the Authorization information. Isn't this true for all systems. If there isn't at least a minimal amount of trust nothing at all can be accomplished. William Marshall @ietf.org on 03/27/2002 05:18:57 PM Sent by: sip-admin@ietf.org To: sip@ietf.org cc: Subject: Re: [Sip] Comment, SIP Privacy draft In all the criticism and discussion of draft-ietf-sip-privacy, there has been one fact conveniently overlooked - the facilities already in bis-09. I find them scary. When a UAC sends an INVITE and is challenged by a proxy, and responds with the authentication credentials, the proxy has ascertained the identity of the UAC. The proxy can then add a "Call-Info" header to the INVITE that contains whatever identity information it wants. See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element." How? No clue is given. Note that with "Call-Info" headers can appear in both requests and responses, and may be used by the UAC/UAS for presentation, there are *no* restrictions on what this information could be, *no* restrictions on how far it is propagated, *no* requirement that it be encrypted, and *no* mechanism for the UAC/UAS to request that this not be done. In that sense, draft-ietf-sip-privacy *really* is about privacy. It includes a mechanism whereby the UAC can request that its identity be kept private and that proxies NOT include information (which the proxies will obtain and know) in the message that is forwarded to the destination. The entire rest of the draft deals with the consequences of this request. I find it very surprising that an attempt to restrict the use of the Call-Info header (thereby requiring a new header name, Remote-Party-ID) is meeting with such objection, when there was absolutely no comment on the Call-Info usage (and no applicability statement attached to it) during the WGLC or AD review of 2543bis. From a service provider point of view, I'm not sure I see a difference between requiring certain proxy behavior with respect to the "Call-Info" headers, than requiring the same proxy behavior with "Remote-Party-ID" headers. Codifing the requirements would be useful in either case; and doing this with purchase orders is likely not the best way to do this. However, I do believe Remote-Party-ID is more general than Call-Info, and solves a bigger piece of the problem. While sufficient mechanism exists in bis-09 to do CLIP/CLIR through the use of Call-Info headers, it is without the ability of the UAC/UAS to know that its anonymity request will be honored (presumably signaled through use of "Anonymous" in the display-name of the From header). Better trust that proxy when you send the Authorization information. Bill Marshall wtm@research.att.com -----original message----- Date: Wed, 27 Mar 2002 12:08:45 -0800 To: Flemming Andreasen From: Matt Holdrege Subject: Re: [Sip] Comment, SIP Privacy draft Cc: Dean Willis , sip@ietf.org At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > Matt Holdrege wrote: > > You can work on the > > more general case and I fully support that. But some of us still care about > > interworking with the PSTN and we need to get that bit specified ASAP > > before the world is polluted with proprietary SIP headers. > >If that's all you want it's pretty easy: Just add an ISUP body to all >your SIP >messages and fill in the blanks. However some of us were hoping for >something a >little more general and useful. No, we actually need the Remote Party ID and restricted flag. I also hope for a more general and useful way to deal with privacy. But it seems like that's going to be a difficult sell or at least a longer term project than originally expected. So it would be nice to get something less out the door now so that Service Providers can use it today, and the ITU-T and 3GPP won't go off and do something to the SIP headers that the IETF doesn't support. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 09:57:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28971 for ; Thu, 28 Mar 2002 09:57:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA20609 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 09:57:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18170; Thu, 28 Mar 2002 09:08:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18138 for ; Thu, 28 Mar 2002 09:08:14 -0500 (EST) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26441 for ; Thu, 28 Mar 2002 09:08:07 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2SE7a315974; Thu, 28 Mar 2002 15:07:36 +0100 (MET) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 14:07:40 -0000 Message-ID: From: "Mark Watson" To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Thu, 28 Mar 2002 14:07:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D661.E79140B4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C1D661.E79140B4 Content-Type: text/plain Must say I hadn't spotted this - Bill makes some very good points. It's worth noting that it would not be legal in most places to build a publically available service based on proxy insertion of the Call-Info. There is no way for the user to indicate on a call by call basis whether the proxy should insert the Call-Info or not. This capability would be required to have this as part of a publically available service, even if you do have a trust relationship with your home proxy etc. etc. The bis-09 text implies that proxies could insert this field but makes no statements to warn service designers about the legal minefield they would thus be entering. Very unfortunate when a single Call-Info-Restriction indicator would have solved the problem. It was exactly statements about needing to 'verify the authenticity of the element that originated the header field and trust that element' which have generated howls of protest over Remote-Party-ID, even though the RPID draft always described the trust model within which this was possible. How exactly *can* you determine who added a particular header and whether you trust them, outside of the type of scenario described in the RPID draft ? Perhaps we should deprecate Call-Info immediately and replace it with Remote-Party-ID ? ...Mark > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 27 March 2002 22:19 > To: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > In all the criticism and discussion of draft-ietf-sip-privacy, there > has been one fact conveniently overlooked - the facilities already > in bis-09. I find them scary. > > When a UAC sends an INVITE and is challenged by a proxy, and responds > with the authentication credentials, the proxy has ascertained the > identity of the UAC. The proxy can then add a "Call-Info" header > to the INVITE that contains whatever identity information it wants. > See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED > that a UA only render the information in the Call-Info header field if > it can verify the authenticity of the element that originated the > header field and trusts that element." How? No clue is given. > > Note that with "Call-Info" headers can appear in both requests > and responses, and may be used by the UAC/UAS for presentation, > there are *no* restrictions on what this information could be, *no* > restrictions on how far it is propagated, *no* requirement that it > be encrypted, and *no* mechanism for the UAC/UAS to request that this > not be done. > > In that sense, draft-ietf-sip-privacy *really* is about privacy. > It includes a mechanism whereby the UAC can request that its > identity be kept private and that proxies NOT include information > (which the proxies will obtain and know) in the message that is > forwarded to the destination. The entire rest of the draft deals > with the consequences of this request. > > I find it very surprising that an attempt to restrict the use of the > Call-Info header (thereby requiring a new header name, > Remote-Party-ID) > is meeting with such objection, when there was absolutely no comment > on the Call-Info usage (and no applicability statement attached to it) > during the WGLC or AD review of 2543bis. > > From a service provider point of view, I'm not sure I see a difference > between requiring certain proxy behavior with respect to the > "Call-Info" > headers, than requiring the same proxy behavior with "Remote-Party-ID" > headers. Codifing the requirements would be useful in either case; > and doing this with purchase orders is likely not the best way to do > this. > > However, I do believe Remote-Party-ID is more general than Call-Info, > and solves a bigger piece of the problem. While sufficient > mechanism exists in bis-09 to do CLIP/CLIR through the use of > Call-Info headers, it is without the ability of the UAC/UAS to know > that its anonymity request will be honored (presumably > signaled through > use of "Anonymous" in the display-name of the From header). > > Better trust that proxy when you send the Authorization information. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Wed, 27 Mar 2002 12:08:45 -0800 > To: Flemming Andreasen > From: Matt Holdrege > Subject: Re: [Sip] Comment, SIP Privacy draft > Cc: Dean Willis , sip@ietf.org > > At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > > Matt Holdrege wrote: > > > You can work on the > > > more general case and I fully support that. But some of > us still care about > > > interworking with the PSTN and we need to get that bit > specified ASAP > > > before the world is polluted with proprietary SIP headers. > > > >If that's all you want it's pretty easy: Just add an ISUP > body to all > >your SIP > >messages and fill in the blanks. However some of us were hoping for > >something a > >little more general and useful. > > No, we actually need the Remote Party ID and restricted flag. > I also hope > for a more general and useful way to deal with privacy. But > it seems like > that's going to be a difficult sell or at least a longer term > project than > originally expected. So it would be nice to get something > less out the door > now so that Service Providers can use it today, and the ITU-T > and 3GPP > won't go off and do something to the SIP headers that the > IETF doesn't support. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1D661.E79140B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Comment, SIP Privacy draft

Must say I hadn't spotted this - Bill makes some very = good points.

It's worth noting that it would not be legal in most = places to build a publically available service based on proxy insertion = of the Call-Info. There is no way for the user to indicate on a call by = call basis whether the proxy should insert the Call-Info or not. This = capability would be required to have this as part of a publically = available service, even if you do have a trust relationship with your = home proxy etc. etc.

The bis-09 text implies that proxies could insert = this field but makes no statements to warn service designers about the = legal minefield they would thus be entering. Very unfortunate when a = single Call-Info-Restriction indicator would have solved the = problem.

It was exactly statements about needing to 'verify = the authenticity of the element that originated the header field and = trust that element' which have generated howls of protest over = Remote-Party-ID, even though the RPID draft always described the trust = model within which this was possible.

How exactly *can* you determine who added a = particular header and whether you trust them, outside of the type of = scenario described in the RPID draft ?

Perhaps we should deprecate Call-Info immediately and = replace it with Remote-Party-ID ?

...Mark

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: 27 March 2002 22:19
> To: sip@ietf.org
> Subject: Re: [Sip] Comment, SIP Privacy = draft
>
>
> In all the criticism and discussion of = draft-ietf-sip-privacy, there
> has been one fact conveniently overlooked - the = facilities already
> in bis-09.  I find them scary.
>
> When a UAC sends an INVITE and is challenged by = a proxy, and responds
> with the authentication credentials, the proxy = has ascertained the
> identity of the UAC.  The proxy can then = add a "Call-Info" header
> to the INVITE that contains whatever identity = information it wants.
> See Section 20.9 of 2543bis-09.  As for = the UAS, "It is RECOMMENDED
> that a UA only render the information in the = Call-Info header field if
> it can verify the authenticity of the element = that originated the
> header field and trusts that = element."  How?  No clue is given.
>
> Note that with "Call-Info" headers = can appear in both requests
> and responses, and may be used by the UAC/UAS = for presentation,
> there are *no* restrictions on what this = information could be, *no*
> restrictions on how far it is propagated, *no* = requirement that it
> be encrypted, and *no* mechanism for the = UAC/UAS to request that this
> not be done.
>
> In that sense, draft-ietf-sip-privacy *really* = is about privacy.
> It includes a mechanism whereby the UAC can = request that its
> identity be kept private and that proxies NOT = include information
> (which the proxies will obtain and know) in the = message that is
> forwarded to the destination.  The entire = rest of the draft deals
> with the consequences of this request.
>
> I find it very surprising that an attempt to = restrict the use of the
> Call-Info header (thereby requiring a new = header name,
> Remote-Party-ID)
> is meeting with such objection, when there was = absolutely no comment
> on the Call-Info usage (and no applicability = statement attached to it)
> during the WGLC or AD review of 2543bis.
>
> From a service provider point of view, I'm not = sure I see a difference
> between requiring certain proxy behavior with = respect to the
> "Call-Info"
> headers, than requiring the same proxy behavior = with "Remote-Party-ID"
> headers.  Codifing the requirements would = be useful in either case;
> and doing this with purchase orders is likely = not the best way to do
> this. 
>
> However, I do believe Remote-Party-ID is more = general than Call-Info,
> and solves a bigger piece of the problem.  = While sufficient
> mechanism exists in bis-09 to do CLIP/CLIR = through the use of
> Call-Info headers, it is without the ability of = the UAC/UAS to know
> that its anonymity request will be honored = (presumably
> signaled through
> use of "Anonymous" in the = display-name of the From header). 
>
> Better trust that proxy when you send the = Authorization information.
>
> Bill Marshall
> wtm@research.att.com
>
> -----original message-----
> Date: Wed, 27 Mar 2002 12:08:45 -0800
> To: Flemming Andreasen = <fandreas@cisco.com>
> From: Matt Holdrege = <matt.holdrege@verizon.net>
> Subject: Re: [Sip] Comment, SIP Privacy = draft
> Cc: Dean Willis = <dean.willis@softarmor.com>, sip@ietf.org
>
> At 11:57 AM 3/27/2002, Flemming Andreasen = wrote:
> > Matt Holdrege wrote:
> > > You can work on the
> > > more general case and I fully support = that. But some of
> us still care about
> > > interworking with the PSTN and we = need to get that bit
> specified ASAP
> > > before the world is polluted with = proprietary SIP headers.
> >
> >If that's all you want it's pretty = easy:    Just add an ISUP
> body to all
> >your SIP
> >messages and fill in the blanks. However = some of us were hoping for
> >something a
> >little more general and useful.
>
> No, we actually need the Remote Party ID and = restricted flag.
> I also hope
> for a more general and useful way to deal with = privacy. But
> it seems like
> that's going to be a difficult sell or at least = a longer term
> project than
> originally expected. So it would be nice to get = something
> less out the door
> now so that Service Providers can use it today, = and the ITU-T
> and 3GPP
> won't go off and do something to the SIP = headers that the
> IETF doesn't support.
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1D661.E79140B4-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 12:18:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06693 for ; Thu, 28 Mar 2002 12:18:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA00115 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 12:18:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25364; Thu, 28 Mar 2002 11:24:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25333 for ; Thu, 28 Mar 2002 11:24:12 -0500 (EST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03123 for ; Thu, 28 Mar 2002 11:24:06 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 08:23:39 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Mar 2002 08:23:39 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 08:23:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 28 Mar 2002 08:23:31 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Thu, 28 Mar 2002 08:20:13 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Comment, SIP Privacy draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Date: Thu, 28 Mar 2002 08:20:14 -0800 Message-ID: Thread-Topic: [Sip] Comment, SIP Privacy draft thread-index: AcHWQtnDNpObqsFeSFeKcQ38MjKeqQALsnrA From: "Christian Huitema" To: "Mark Watson" , "Flemming Andreasen" Cc: "Dean Willis" , X-OriginalArrivalTime: 28 Mar 2002 16:20:13.0786 (UTC) FILETIME=[70AA8BA0:01C1D674] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA25334 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > The reference to "Public telephony server" above is very misplaced. 3GPP & > DCS SIP networks are not telephony networks. We need less of this > invective and more focus on the real problems. The reference was not an invective, but rather an acknowledgement of legal implications of providing a "public service". The requirements to be able to provide call tracing applies to public services, and result in a requirement to have something like the remote party ID. It is quite unclear that such a requirement applies to a private service, e.g. direct calls over the Internet between two corporations. OTOH, the existence of technologies such as remote-party ID have to be taken into account when devising a privacy solution: we must assume that whatever information is given to the network will be disclosed. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 12:34:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07282 for ; Thu, 28 Mar 2002 12:34:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01173 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 12:34:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27383; Thu, 28 Mar 2002 11:51:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27352 for ; Thu, 28 Mar 2002 11:51:53 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04838 for ; Thu, 28 Mar 2002 11:51:47 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2SGpFY16284; Thu, 28 Mar 2002 08:51:18 -0800 (PST) Received: from OranLT ([161.44.238.53]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACL35566; Thu, 28 Mar 2002 08:51:24 -0800 (PST) From: "David R. Oran" To: "'Alan O'Neill'" , "'Gonzalo Camarillo'" Cc: Subject: RE: [Sip] RE: Manyfolks draft wording Date: Thu, 28 Mar 2002 11:47:08 -0500 Organization: Cisco Systems Message-ID: <00d101c1d678$33f81340$35ee2ca1@OranLT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <8C92E23A3E87FB479988285F9E22BE46C39A95@ftmail> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've reread this thread twice now, and I'm puzzled at why we seem to be talking past each other. Here's a little gedanken-experiment to try. Replace every instance of the term "QoS" in the thread with "admission control". That's what we're really talking about here; not QoS itself. Having done that, has anything changed? Well, we certainly can stop talking about who puts what QoS (if any) on the actual media flows. Then we can talk (I hope) clearly about what inference one party can make about the admission control procedures and state feedback via a QoS signaling protocol it expects from the other party. If that doesn't in fact help clarify anything.....back to your regularly-scheduled program. Dave. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Alan O'Neill > Sent: Tuesday, March 26, 2002 1:39 AM > To: Gonzalo Camarillo > Cc: 'sip@ietf.org ' > Subject: [Sip] RE: Manyfolks draft wording > > > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 25 March 2002 14:19 > To: Alan O'Neill > Cc: 'sip@ietf.org ' > Subject: Re: Manyfolks draft wording > > > Hello, > > > > I stated that "e2e reservations do not 'necessarily' ensure > end to end > QoS". > > Yes, we have been speaking about this for a while already. > What manyfolks provides you is a hook between the application > and the reservation protocol. > > When the reservation protocol is an e2e protocol (e.g., > RSVP), you need to know when the send and the recv directions > are ready in order to resume session establishment. > > This framework assumes that when the reservation protocol > says that the send direction is ready, it is true. What you > are saying is that the framework should say: "when the other > end tells you that the send direction is ready, don't believe > it, because it is not necessarily so. e2e reservation > protocols do not work, so the other end is missinformed when > he states that resources in the send directions are reserved." > > AWO> Not what I am saying at all. If I have an SLA covering that end > AWO> point > and the networks in between then I can believe but if I do > not then I cannot becasue no-one is going to book resources > for me for nothing. You only believe the e2e protocol because > of other knowledge you have with the 3G system that has an > implied SLA with it. Basically, your protocol design relies > on the fact that 3G will ensure all e2e tags are adequately > supported in the core dimensioning and through PDPcontext > activation in the access. This is an SLA covering 3G and yes > this will work for 3G...The general case though is very > different and hence why I am reacting to your design and the > wording in the draft. > > What I am trying to say is that the fact that e2e reservation > protocols may not ensure e2e QoS is not a problem of the > framework but a problem of the reservation protocol itself. > The manyfolks framework should not describe whether > reservation protocols work or not. It only transports the > information the resource reservation protocols provides (that > is, the status of resource reservation as seen by the > resource reservation protocol). > > aWO> No - it is not a problem with the protocol at all but of the > aWO> framework > because you do not in anyway cover SLAs (ie customer > commitments). RSVP as an example books resources but they can > only be booked if they are available to you from a policy > perspective in the places you are trying to call..these are > SLA issues. You have written a draft that states absolutes > about QoS mechanisms that are in fact variables based on the > deployment scenarion and associated SLAs...thats all. You are > therefore 3G and DCS specific and unrepresentative of the > rest of the net and how operators sell QoS.. > > Take into account that if you want preconditions to work, you > have to trust the reservation protocol. If you receive a > messages saying: "I have reserved resources in the send > direction", and you do not trust it, preconditions are > useless. Since you could not be sure whether or not the > preconditions were met, you would never resume sessione establishment. > > AWO> Trusting the protocol is not at issue here..The protocol does not > convey the information you require. If RSVP says there is a > non-RSVP cloud you don't know where it is and therefore do > not know what to do about. If the non-RSVP cloud is > encountered within 3G you will interpret this as success, and > so you must accept all non-RSVPs as a success becasue you > will surely transition the 3G core in all VoIP cases, and you > can't see if there are additional non-RSVP congested > segments..In both case, the only way to resolve this in the > gneral case is that you only trust the protocol if there is > an SLA covering the path...end of story.. > > > > In the manyfolks draft and in your follow-up to my wording > issue you > > state that segmented does not ensure QoS whilst e2e protocol does. > > Thereby you > are > > stating that segmented is somehow less able to satisfy > preconditions > > and hence, according to my concern, is considered worse in this > > specific > regard. > > > > > If you use e2e status type, there is something in the SDP > that tells you that there are e2e resources. As I said > before, manyfolks assumes that you trusts your reservation protocol. > > AWO> But the UA doesn't know that and it is only known in your head > AWO> becasue > of what you know about 3G..ie the SLA. The reservation > protocol will send non-RSVP cloud which you choose to ignore > because of that SLA commitment.. > > when you use local/remote tags, there is nothing in the SDP > that tells you anything about the backbone. Therefore, there > may be resources or there may not be resources. The fact is > that with the information in the SDP you cannot tell. > > AWO> That is an effect and assumption of the design and hence > the root > AWO> of my > concern. In the case of DOCSIS DQoS I can run bi-RSVP to the > CMTS and reserve the two accesses. In the CMTS I can have a > dimensioned diff-serv cloud into which the bi-RSVP messages > are admitted. I have not used e2e protocol but I have > confirmed e2e QoS to the same level as assurance as when > using the e2e tag. The SLA with my operator to a destination > says whether in principle e2e QoS is possible. The SDP Update > confirms that the QoS set-up within this SLA has succeeded. > The only difference with the signalling is the added 0.5 RTT > becasue I need to use an Update instead of the QoS protocol > feedback. The draft is missing the SLA bit and the relative > wighting of e2e v local/remote adn the associated assumptions > are 3G/DCS specific but in general bogus. Please proceed if > you and the working are happy that someone like me can in the > future write a=des:QoS2 for my QoS mechs and assumptions, and > we will forget about interoperability...sound reasonable ? (I > hope not) > > Alan. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 13:18:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09042 for ; Thu, 28 Mar 2002 13:18:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03580 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 13:18:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01299; Thu, 28 Mar 2002 12:36:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01269 for ; Thu, 28 Mar 2002 12:36:45 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07365 for ; Thu, 28 Mar 2002 12:36:41 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2SHaCF28434 for ; Thu, 28 Mar 2002 12:36:12 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA03497; Thu, 28 Mar 2002 11:36:11 -0600 (CST) Message-ID: <3CA35488.4020800@lucent.com> Date: Thu, 28 Mar 2002 11:36:08 -0600 From: "Vijay K. Gurbani" Organization: Lucent Technologies, Inc./Bell Laboratories User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Updated -09bis with nits review? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks: Is there an online accessible version of -09bis that *includes* modifications resulting from the nits review? Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 13:44:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10089 for ; Thu, 28 Mar 2002 13:44:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05273 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 13:44:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03061; Thu, 28 Mar 2002 13:09:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03029 for ; Thu, 28 Mar 2002 13:09:44 -0500 (EST) Received: from mail.mediatrix.com (mail.mediatrix.com [66.129.134.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08689 for ; Thu, 28 Mar 2002 13:09:42 -0500 (EST) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Mar 2002 13:09:43 -0500 Message-ID: From: Eric Tremblay To: "'jdrosen@dynamicsoft.com'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] Open Issue #203: transport related params in To/From Date: Thu, 28 Mar 2002 13:09:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ouch! This one fell through the cracks, and I'm surprised it did not generate more comments. I know it's kind of late to comment on that and I don't expect any changes, but I want to make sure I understand a few things. 1- Bis06 and later won't interoperate with Bis05 and earlier if Bis05 devices add ports to their From/To headers of their requests. (the port can get stripped in the response, causing a failure to match the response to the request). Our devices are placing the port number in From/To if the home server is listening to something else than 5060 :( Of course, if the Bis06+ device echo the port in responses, everything should work fine. 2- I thought that when I was sending an INVITE to establish a dialog, the URL found in the From: could be used to call me back later on. This URL usually pointed to my home server. If this server has no SRV entries and if it is using a port different than 5060, there is no way for the user I have called to call me back. Am I right? It should work fine as long as SRV records are used. Am I right on the two counts? Regards, EricT -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, December 27, 2001 2:14 To: Jo Hornsby Cc: Robert Sparks; sip@ietf.org Subject: Re: [Sip] Open Issue #203: transport related params in To/From There was one email on this thread supporting the proposal, and the rest of the thread dealt with additional wording that might have to be added in support of it. I will comment on the extra wording bits below, but otherwise, I believe there is consensus to accept the proposal. In that case, port and maddr are disallowed from the To/From URLs. More comments below. Jo Hornsby wrote: > Robert wrote: > >>>>Issue: >>>> >>>>Minor issue. Table 1 indicates that in the From/To fields, a >>>>SIP URL cannot contain an maddr, but can contain a port. >>>>This seems odd. Either all addressing params should be >>>>allowed (port, transport, ttl, maddr) else none of them. >>>> >>>>Proposal: >>>> >>>>From/To are supposed to be logical addresses, so neither port >>>>nor maddr nor any of the others make much sense there. >>>>Proposal is to remove unless anyone is sending with these >>>>parameters. >>>> >>>Sounds good to me. >>> >>>If this approach is adopted, am I right in thinking we will >>>have to be _very_ strict about refusing requests that have >>>these parameters (else I can see nasty SIP URL comparison >>>issues ariving)? >>> >>Why not ignore them if present? I can't think of any comparison >>issues taking that approach that don't also exist in deciding to >>reject the message based on the contents of the URL. >> > > I think what I was envisaging was some entity on > the network ignoring these parameters, and then > due to some sort of weird transaction keying > interaction, actually removing them when it > responded or proxied sommat. In this context, having these parameters be "disallowed" means they MUST NOT be inserted, and MUST be ignored by any element that receives them there. So, to be honest, if you do put them in the To field, and the result is that they get stripped when they come back to you, well, thats your problem. Bets are off when you send invalid messages. An implementation might be nice enough to handle it anyway for you, but its not something the spec would mandate. > Also, if we take the approach that they should > just be ignored, then what happens if two requests > arrive that are otherwise identical apart from the > port in the To:, say? They are identical. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Mar 28 15:17:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13370 for ; Thu, 28 Mar 2002 15:17:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA10645 for sip-archive@odin.ietf.org; Thu, 28 Mar 2002 15:17:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09032; Thu, 28 Mar 2002 14:43:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09001 for ; Thu, 28 Mar 2002 14:43:37 -0500 (EST) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12493 for ; Thu, 28 Mar 2002 14:43:34 -0500 (EST) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id LAA17730; Thu, 28 Mar 2002 11:42:51 -0800 (PST) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 11:42:51 -0800 Message-ID: <1C1EEC765F843E44996971A80682118B014B1184@opwinex01.corp.illuminet.com> From: Kevin McCandless To: "'Matt Holdrege'" , Dean Willis , "'Flemming Andreasen'" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Thu, 28 Mar 2002 11:42:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree with this statement. The draft could better renamed and be less confusing by calling it "Caller ID Support". Kevin > -----Original Message----- > From: Matt Holdrege [mailto:matt.holdrege@verizon.net] > Sent: Wednesday, March 27, 2002 12:35 AM > To: Dean Willis; 'Flemming Andreasen' > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > > > Furthermore, per the AS this really has nothing to do with > Privacy. If this > draft is simply to meet the needs of supporting Caller-ID in > SIP to PSTN > scenarios, you should remove the word "privacy" from the > entire draft and > replace it with "screening". Then perhaps you can create a > separate draft > which deals with more pure Internet scenarios for privacy. > > I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball > rolling on that one so we can get it out of the way and work on more > interesting stuff. > > > At 06:57 PM 3/26/2002, Dean Willis wrote: > > > > > I would argue that the draft goes outside its applicability > > > > > statement anytime it discusses providing privacy. > > > > > > This seems rather backwards to me. Are you saying that the > > > applicability statement is an exhaustive listing of scope and > > > requirements and anything that is not listed in there can by > > > definiton not be mentioned in the document ? > > > >Well, I'm suggesting that the draft SHOULD NOT include functionality > >that is clearly OUTSIDE the scope specified by the applicability > >statement. That's why we're getting the push back saying the > document is > >inconsistent with the AS. Why should a draft present > mechanisms to solve > >problems for which the draft declares itself "not applicable"? That > >means either adjust the scope of the draft, or adjust the > scope of the > >AS, as needed and allowed by our "spirit guides" in the IESG . . . > > > > > > As written, it DOESN'T provide > > > > > > > > > privacy. It provides a means whereby a user can REQUEST > > > that network > > > > > elements NOT PUBLISH additional information that, if > published, > > > > > would compromise privacy. > > > > > > Well, it notes that there are different degrees of privacy > > > and provides procedures for not only hiding this additional > > > information, but also discussion about other headers that > > > need to hidden. It also discusses IP address privacy, which > > > will give you full privacy, however, at your request, the > > > Anonymity header that used to solve this was removed, but the > > > issue is still discussed. > > > >Could I propose we abstract that discussion of privacy > concepts into the > >baseline of a general privacy requirements and definition doc? That > >would be cool! We need such a doc, and it would help manage > the "Scope > >vs AS" issues on this doc. > > > > > > I believe that "publish", in the context of this > > > > > document, means "distribute outside a group of proxies > > > with a shared > > > > > administrative policy of mutual trust." > > > > > > Proxies or User Agents. Also, do not forget the call trace > > > requirement, which was an integral part of the motivation > > > behind this draft (of course per your argument, we now can't > > > support call trace either since that's not part of the > > > applicability statement). > > > >Well, that gives us good reason to push back on the AS. > OTOH, I bet the > >security droids would chew on us less if the "sensitive" information > >were always cryptoprotected, as you propose to do to meet the > >call-traceback-from-outside-the-trust-domain requirement. > > > > > > > > > > > > And I think it is the lack of mutual understanding > > > agreement at this > > > > > level that is the holdup. > > > > > > I have no idea what the continued holdup is since there's > > > rarely anything concrete on the table on the mailing list. It > > > would be helpful if we got something from the people that > > > have concerns. > > > >Color me "concerned". > > > >-- > >Dean > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 03:47:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07044 for ; Fri, 29 Mar 2002 03:47:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA25278 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 03:47:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23467; Fri, 29 Mar 2002 03:03:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23431 for ; Fri, 29 Mar 2002 03:03:50 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06596 for ; Fri, 29 Mar 2002 03:03:46 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2T82wZ01297; Fri, 29 Mar 2002 02:02:58 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 02:02:53 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A2@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:02:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A note on the paragraph below. First, I don't think that the applicability statement in sip-privacy is intended to be an exhaustive list of requirements for the mechanism - quite the opposite, it's a set of restrictions on the use of the mechanism. The need for these restrictions arose from the (concrete) ways in which the mechanism was being applied. I don't actually believe that call trace, as I understand it, requires RPID or any comparable apparatus in SIP signaling. No new protocol mechanism is required for a proxy server to record the results of an authentication (indexed perhaps by Call-ID) so that administrative requests for the identity of the originator of a call can be satisfied. I think RPID actually attempts something a little more ambitious; sharing this identity information in a putatively secure fashion within a community of 'trusted' servers, so that this private identity information is immediately available to any 'trusted' element that inspects the signaling, although it is still concealed from end users. How the applicability statement hinders even this goal, though, is unclear to me. All that the applicability statement restricts is the insertion or receipt of RPID by untrusted elements. Surely this is unrelated to call trace? In short, I doubt that the AS has made call trace an impossible goal for the RPID header. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, March 27, 2002 5:49 AM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > [snip] > > If the AS is trying to be a complete listing of requirements then it is > clearly deficient. Moreover, if this is indeed the intention with an > applicability statement, then it is very concerning, that we have this > applicability statement being forced into the document by our "spirit > guides" at the last minute without any discussion about the actual > requirements. As I mentioned before, call trace completely fell through the > cracks here essentially rendering the draft useless for what it was supposed > to do. As this discussion shows, there is disagreement on other points as > well. > > [snip] > > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 03:57:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07145 for ; Fri, 29 Mar 2002 03:57:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA25487 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 03:57:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24035; Fri, 29 Mar 2002 03:18:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24004 for ; Fri, 29 Mar 2002 03:18:16 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06741 for ; Fri, 29 Mar 2002 03:18:12 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2T8ChZ01448; Fri, 29 Mar 2002 02:12:44 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 02:12:38 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A3@va02.va.neustar.com> From: "Peterson, Jon" To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:12:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It is true that the Call-Info header mechanism is a relatively underspecified and open-ended way of inserting some information, possibly information that could reveal an identity, into SIP messages. If one reads the spec with an open mind, one could construe the Call-Info header as a way that a proxy server could insert an identity on behalf of the sender of a message. In that respect it could be argued (though I think it's a bit of a stretch) that there is arbitrary network-asserted 'identity' information floating around in bis09 that has no adequate authentication or privacy story. Bill is certainly right to assert that many things are underspecified in the SIP family of standards, and that it is dangerous to throw applicability statements when you live in glass houses. Should there be a mechanism in SIP that allows a user agent to suggest that proxies treat their requests privately? Of course. I think the presence of some sort of privacy flag/header in requests is a reasonable way to do so (vide the RPID-Privacy header in sip-privacy today). Guaranteeing privacy entails managing a number of headers that could potentially divulge identity - Call-Info is one of many examples (the open-ended User-Agent and Server headers could also be used as repositories for potentially private data, let alone common headers like Via and Contact). I think that the general privacy story for SIP needs to account for restricting the presentation of data that might appear in any of these headers. The final version of a privacy draft in the SIP WG, IMHO, should answer all these risks. When I request privacy from the network, if the network supports this privacy capability, it should be mindful of the Call-Info header. All that said, I feel that it is somewhat misleading to suggest that Call-Info and RPID actually have a similar function, or more directly, that Call-Info should in fact be replaced with RPID. The note below actually suggests Call-Info could be used to implement a CLIP/CLIR service - suffice it to say I do not believe this was the intention behind 20.9 in bis09. Call-Info is intended to be a way to display optional content to the recipient of a message referenced by something like HTTP URIs. Remote-Party-ID, as far as I can make out, is intended to be a repository for a network-verified SIP URI designating the identity of a party in a session. Prima facie these do not seem co-extensive. Personally, I would be happy to see Call-Info specified in more detail in the standard, and significantly limited in the process. For example, I'm not aware of the motivation to allow proxies to add Call-Info, and on initial reflection that doesn't seem indispensible. I have not exactly found the proponents of RPID to be similarly accomodating. A few specific points on the analogy between Call-Info and RPID. First of all, section 20.9 does not suggest that the Call-Info carries identity information (at least, not in the sense that the From or RPID header carries an identity) - I suppose that the fact that Call-Info could carry any URI means that the spec does not rule out carrying a SIP URI. But throughout bis (including the sole example given in 20.9), this header is used to carry HTTP URLs associated with the originator of the message. Second, to my knowledge no examples are given in which Call-Info is set by a proxy server - I acknowledge that the header can be modified by proxies, but 20.9 suggests that Call-Info is predominantly managed by UAs. Third, nothing in the text of 20.9 suggests that a Call-Info header will be populated as a result of the authentication process. Rather, the RECOMMENDED text cited below merely suggests that you should know the identity of the sender of this message before you follow the URL (again, presuming an HTTP URL) in the Call-Info header - presumably because following arbitrary HTTP URLs can pose known security risks (downloading virus-laden applets, or maybe just annoying audio files). The text does not support a reading of Call-Info in which it is set as a result of the authentication process (as suggested by the account given below). Any resemblance between the two headers further breaks down when we begin to look at the functional behavior of RPID - when it is added, how screening operates, and so forth. The most important difference is that Call-Info entails no concept of trusted and untrusted networks which are most certainly entailed by the RPID header. The use of the RPID header is predicated on the configuration of a set of 'trusted' destinations which can inspect the RPID header, and the assumption that it must be removed if it is transferred to an untrusted entity. Personally, I don't think Call-Info requires any such concept if it is used as the spec seems to intend. The argument that Call-Info is a subset of RPID I also find a little troublesome - when properly configured quite a few SIP headers, including at least To and From, could be represented by RPID. With the current extensibility mechanism in sip-privacy-04 I have no doubt it could be argued that RPID should replace all other means of asserting identity in SIP. Personally, I believe this is a defect of sip-privacy-04 rather than a strength. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Wednesday, March 27, 2002 2:19 PM > To: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > In all the criticism and discussion of draft-ietf-sip-privacy, there > has been one fact conveniently overlooked - the facilities already > in bis-09. I find them scary. > > When a UAC sends an INVITE and is challenged by a proxy, and responds > with the authentication credentials, the proxy has ascertained the > identity of the UAC. The proxy can then add a "Call-Info" header > to the INVITE that contains whatever identity information it wants. > See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED > that a UA only render the information in the Call-Info header field if > it can verify the authenticity of the element that originated the > header field and trusts that element." How? No clue is given. > > Note that with "Call-Info" headers can appear in both requests > and responses, and may be used by the UAC/UAS for presentation, > there are *no* restrictions on what this information could be, *no* > restrictions on how far it is propagated, *no* requirement that it > be encrypted, and *no* mechanism for the UAC/UAS to request that this > not be done. > > In that sense, draft-ietf-sip-privacy *really* is about privacy. > It includes a mechanism whereby the UAC can request that its > identity be kept private and that proxies NOT include information > (which the proxies will obtain and know) in the message that is > forwarded to the destination. The entire rest of the draft deals > with the consequences of this request. > > I find it very surprising that an attempt to restrict the use of the > Call-Info header (thereby requiring a new header name, Remote-Party-ID) > is meeting with such objection, when there was absolutely no comment > on the Call-Info usage (and no applicability statement attached to it) > during the WGLC or AD review of 2543bis. > > From a service provider point of view, I'm not sure I see a difference > between requiring certain proxy behavior with respect to the "Call-Info" > headers, than requiring the same proxy behavior with "Remote-Party-ID" > headers. Codifing the requirements would be useful in either case; > and doing this with purchase orders is likely not the best way to do > this. > > However, I do believe Remote-Party-ID is more general than Call-Info, > and solves a bigger piece of the problem. While sufficient > mechanism exists in bis-09 to do CLIP/CLIR through the use of > Call-Info headers, it is without the ability of the UAC/UAS to know > that its anonymity request will be honored (presumably signaled through > use of "Anonymous" in the display-name of the From header). > > Better trust that proxy when you send the Authorization information. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Wed, 27 Mar 2002 12:08:45 -0800 > To: Flemming Andreasen > From: Matt Holdrege > Subject: Re: [Sip] Comment, SIP Privacy draft > Cc: Dean Willis , sip@ietf.org > > At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > > Matt Holdrege wrote: > > > You can work on the > > > more general case and I fully support that. But some of > us still care about > > > interworking with the PSTN and we need to get that bit > specified ASAP > > > before the world is polluted with proprietary SIP headers. > > > >If that's all you want it's pretty easy: Just add an ISUP > body to all > >your SIP > >messages and fill in the blanks. However some of us were hoping for > >something a > >little more general and useful. > > No, we actually need the Remote Party ID and restricted flag. > I also hope > for a more general and useful way to deal with privacy. But > it seems like > that's going to be a difficult sell or at least a longer term > project than > originally expected. So it would be nice to get something > less out the door > now so that Service Providers can use it today, and the ITU-T > and 3GPP > won't go off and do something to the SIP headers that the > IETF doesn't support. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 04:13:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07290 for ; Fri, 29 Mar 2002 04:13:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA26293 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 04:13:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24383; Fri, 29 Mar 2002 03:28:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24352 for ; Fri, 29 Mar 2002 03:28:04 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06845 for ; Fri, 29 Mar 2002 03:28:00 -0500 (EST) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2T8R7825076; Fri, 29 Mar 2002 03:27:07 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 02:27:02 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A4@va02.va.neustar.com> From: "Peterson, Jon" To: "'Mark Watson'" , "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:27:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A few more things about this Call-Info business. Firstly, nothing in the SIP standard that I'm aware of suggests that there would be some sort of telephony service based on the proxy insertion of Call-Info. As far as I know Call-Info is not intended to be an identity-assertion mechanism. Agreed that the spec does not rule out proxy servers adding the header, but at the same time the spec doesn't suggest any conditions under which proxies could or should add Call-Info. Call-Info clearly exists for a purpose unrelated to privacy/identity management, although I concede that its intended use may have its own privacy implications. But do your concerns about the legality of publically available services extend to instant messaging, Internet gaming, and the like? I'd further note that I'm not sure that it is the responsibility of each SIP header to provide its own mechanism by which a UA can specify whether or not they would like the header to be added or modified by proxy servers. Rather, I think a request by the end user for privacy from the network should apply to any headers that would potentially divulge private information. So in other words, I think that a mechanism comparable to the RPID-Privacy header in sip-privacy-04 should allow a UA to specify how the network should deal with their private identity information, regardless of the header in which that information appears (including From, Call-Info, or what have you). On another matter, note that sip-privacy-04 provides no mechanism that allows the recipient of messages to authenticate the party that added a particular header - sip-privacy only ensures that some 'trusted' entity, rather than an untrusted entity, has added a screened RPID. The only SIP headers I'm aware of that contain cryptographic authentication are described in the Digest section of bis09 - headers of this form allow one to ascertain the identity of the party that generated the header. RPID assumes some out-of-band mechanism by which an authenticated identity is discovered which is in turn persisted in the RPID header. I'd therefore say that RPID offers no improvement on Call-Info with regard to identifying the party that added the header. I might also add that I for one have not particularly howled about the lack of this feature (it would be nice as a general property of SIP headers, like for Via, but this isn't in the scope of this priblem). I'm only howling about the use of RPID outside the context of network-verified identity in support of privacy. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, March 28, 2002 6:08 AM To: 'William Marshall'; sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Must say I hadn't spotted this - Bill makes some very good points. It's worth noting that it would not be legal in most places to build a publically available service based on proxy insertion of the Call-Info. There is no way for the user to indicate on a call by call basis whether the proxy should insert the Call-Info or not. This capability would be required to have this as part of a publically available service, even if you do have a trust relationship with your home proxy etc. etc. The bis-09 text implies that proxies could insert this field but makes no statements to warn service designers about the legal minefield they would thus be entering. Very unfortunate when a single Call-Info-Restriction indicator would have solved the problem. It was exactly statements about needing to 'verify the authenticity of the element that originated the header field and trust that element' which have generated howls of protest over Remote-Party-ID, even though the RPID draft always described the trust model within which this was possible. How exactly *can* you determine who added a particular header and whether you trust them, outside of the type of scenario described in the RPID draft? Perhaps we should deprecate Call-Info immediately and replace it with Remote-Party-ID? ...Mark > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 27 March 2002 22:19 > To: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > In all the criticism and discussion of draft-ietf-sip-privacy, there > has been one fact conveniently overlooked - the facilities already > in bis-09. I find them scary. > > When a UAC sends an INVITE and is challenged by a proxy, and responds > with the authentication credentials, the proxy has ascertained the > identity of the UAC. The proxy can then add a "Call-Info" header > to the INVITE that contains whatever identity information it wants. > See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED > that a UA only render the information in the Call-Info header field if > it can verify the authenticity of the element that originated the > header field and trusts that element." How? No clue is given. > > Note that with "Call-Info" headers can appear in both requests > and responses, and may be used by the UAC/UAS for presentation, > there are *no* restrictions on what this information could be, *no* > restrictions on how far it is propagated, *no* requirement that it > be encrypted, and *no* mechanism for the UAC/UAS to request that this > not be done. > > In that sense, draft-ietf-sip-privacy *really* is about privacy. > It includes a mechanism whereby the UAC can request that its > identity be kept private and that proxies NOT include information > (which the proxies will obtain and know) in the message that is > forwarded to the destination. The entire rest of the draft deals > with the consequences of this request. > > I find it very surprising that an attempt to restrict the use of the > Call-Info header (thereby requiring a new header name, > Remote-Party-ID) > is meeting with such objection, when there was absolutely no comment > on the Call-Info usage (and no applicability statement attached to it) > during the WGLC or AD review of 2543bis. > > From a service provider point of view, I'm not sure I see a difference > between requiring certain proxy behavior with respect to the > "Call-Info" > headers, than requiring the same proxy behavior with "Remote-Party-ID" > headers. Codifing the requirements would be useful in either case; > and doing this with purchase orders is likely not the best way to do > this. > > However, I do believe Remote-Party-ID is more general than Call-Info, > and solves a bigger piece of the problem. While sufficient > mechanism exists in bis-09 to do CLIP/CLIR through the use of > Call-Info headers, it is without the ability of the UAC/UAS to know > that its anonymity request will be honored (presumably > signaled through > use of "Anonymous" in the display-name of the From header). > > Better trust that proxy when you send the Authorization information. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Wed, 27 Mar 2002 12:08:45 -0800 > To: Flemming Andreasen > From: Matt Holdrege > Subject: Re: [Sip] Comment, SIP Privacy draft > Cc: Dean Willis , sip@ietf.org > > At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > > Matt Holdrege wrote: > > > You can work on the > > > more general case and I fully support that. But some of > us still care about > > > interworking with the PSTN and we need to get that bit > specified ASAP > > > before the world is polluted with proprietary SIP headers. > > > >If that's all you want it's pretty easy: Just add an ISUP > body to all > >your SIP > >messages and fill in the blanks. However some of us were hoping for > >something a > >little more general and useful. > > No, we actually need the Remote Party ID and restricted flag. > I also hope > for a more general and useful way to deal with privacy. But > it seems like > that's going to be a difficult sell or at least a longer term > project than > originally expected. So it would be nice to get something > less out the door > now so that Service Providers can use it today, and the ITU-T > and 3GPP > won't go off and do something to the SIP headers that the > IETF doesn't support. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 06:22:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08562 for ; Fri, 29 Mar 2002 06:22:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA01138 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 06:22:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00186; Fri, 29 Mar 2002 05:55:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00156 for ; Fri, 29 Mar 2002 05:55:37 -0500 (EST) Received: from nausicaa.coritel.it (IDENT:root@[193.205.242.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08270 for ; Fri, 29 Mar 2002 05:55:31 -0500 (EST) Received: from archimede (archimede [141.137.43.43]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id g2TB0BP31907 for ; Fri, 29 Mar 2002 12:00:11 +0100 Message-ID: <029d01c1d70f$c288a1a0$2b2b898d@coritel.it> From: "Andrea Floris" To: Date: Fri, 29 Mar 2002 11:51:54 +0100 Organization: CoRiTeL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] a question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'd like to know what the current standardization state about the integration of the Session Initiation Protocol with a general AAA architecture is. Which is the related Standardization Group within IETF? Where can I find some documents/drafts/slides/papers about that problem? In particular, I'm mainly interested in issues related to a combined SIP-AAA architecture for support of global roaming. Best regards ----------------------------------------------- Andrea Floris Research Engineer IP Networking Area e-mail: floris@coritel.it tel.: + 39 06 72589120 fax: + 39 06 72583002 URL: http://www.coritel.it/ ----------------------------------------------- CoRiTel - Research Center on Telecommunications Ericsson Lab Italy SpA Via Anagnina, 203 00040 Morena - Rome - Italy ----------------------------------------------- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 09:02:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14017 for ; Fri, 29 Mar 2002 09:02:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08188 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 09:02:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05905; Fri, 29 Mar 2002 08:23:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05874 for ; Fri, 29 Mar 2002 08:23:40 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11664 for ; Fri, 29 Mar 2002 08:23:36 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 67A804CE75; Fri, 29 Mar 2002 08:23:39 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA06471; Fri, 29 Mar 2002 08:23:35 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA39748; Fri, 29 Mar 2002 08:21:08 -0500 (EST) Date: Fri, 29 Mar 2002 08:21:08 -0500 (EST) Message-Id: <200203291321.IAA39748@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jon Peterson wrote: > If one reads > the spec with an open mind, one could construe the Call-Info header as a way > that a proxy server could insert an identity on behalf of the sender of a > message. I don't think it takes much of an open mind in reading the spec, since (1) 20.9 says a proxy can insert a Call-Info header (2) Table 2 says a proxy can add or concatenate the header field if not present (3) Table 2 says a proxy must be able to read the header field So it is clearly the intent of this header that the proxy be able to insert it; the only question is under what conditions. Granted it is underspecified, and inserting bad information is just as allowable as inserting good information. But I think a reasonable interpretation of the existing text in bis-09 is that a proxy inserts this header as a result of the authentication exchange. As an example: Call-Info: ;purpose=info Call-Info: ;purpose=info So CLIP is easy. And it is certainly dangerous to presume a http URL, when the spec contains no such limit. > The argument that Call-Info is a subset of RPID I also find a little > troublesome ... There was no attempt to claim that Call-Info was a subset of RPID, rather that the RPID is actually a set of restrictions on the allowable use of Call-Info. RPID is a very restricted subset of Call-Info. Note that Call-Info contains all the extensibility mechanisms as RPID. And, in another message (also attached), Jon wrote: > On another matter, note that sip-privacy-04 provides no mechanism that > allows the recipient of messages to authenticate the party that added a > particular header - sip-privacy only ensures that some 'trusted' entity, > rather than an untrusted entity, has added a screened RPID. As has been answered many times, previous versions of the privacy draft did include this, but it was removed in favor of a general (still to be defined) mechanism usable for other headers, too. The extension mechanisms was specifically designed to allow this authentication. You can't both complain that it is there and complain that it isn't. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:12:36 -0600 It is true that the Call-Info header mechanism is a relatively underspecified and open-ended way of inserting some information, possibly information that could reveal an identity, into SIP messages. If one reads the spec with an open mind, one could construe the Call-Info header as a way that a proxy server could insert an identity on behalf of the sender of a message. In that respect it could be argued (though I think it's a bit of a stretch) that there is arbitrary network-asserted 'identity' information floating around in bis09 that has no adequate authentication or privacy story. Bill is certainly right to assert that many things are underspecified in the SIP family of standards, and that it is dangerous to throw applicability statements when you live in glass houses. Should there be a mechanism in SIP that allows a user agent to suggest that proxies treat their requests privately? Of course. I think the presence of some sort of privacy flag/header in requests is a reasonable way to do so (vide the RPID-Privacy header in sip-privacy today). Guaranteeing privacy entails managing a number of headers that could potentially divulge identity - Call-Info is one of many examples (the open-ended User-Agent and Server headers could also be used as repositories for potentially private data, let alone common headers like Via and Contact). I think that the general privacy story for SIP needs to account for restricting the presentation of data that might appear in any of these headers. The final version of a privacy draft in the SIP WG, IMHO, should answer all these risks. When I request privacy from the network, if the network supports this privacy capability, it should be mindful of the Call-Info header. All that said, I feel that it is somewhat misleading to suggest that Call-Info and RPID actually have a similar function, or more directly, that Call-Info should in fact be replaced with RPID. The note below actually suggests Call-Info could be used to implement a CLIP/CLIR service - suffice it to say I do not believe this was the intention behind 20.9 in bis09. Call-Info is intended to be a way to display optional content to the recipient of a message referenced by something like HTTP URIs. Remote-Party-ID, as far as I can make out, is intended to be a repository for a network-verified SIP URI designating the identity of a party in a session. Prima facie these do not seem co-extensive. Personally, I would be happy to see Call-Info specified in more detail in the standard, and significantly limited in the process. For example, I'm not aware of the motivation to allow proxies to add Call-Info, and on initial reflection that doesn't seem indispensible. I have not exactly found the proponents of RPID to be similarly accomodating. A few specific points on the analogy between Call-Info and RPID. First of all, section 20.9 does not suggest that the Call-Info carries identity information (at least, not in the sense that the From or RPID header carries an identity) - I suppose that the fact that Call-Info could carry any URI means that the spec does not rule out carrying a SIP URI. But throughout bis (including the sole example given in 20.9), this header is used to carry HTTP URLs associated with the originator of the message. Second, to my knowledge no examples are given in which Call-Info is set by a proxy server - I acknowledge that the header can be modified by proxies, but 20.9 suggests that Call-Info is predominantly managed by UAs. Third, nothing in the text of 20.9 suggests that a Call-Info header will be populated as a result of the authentication process. Rather, the RECOMMENDED text cited below merely suggests that you should know the identity of the sender of this message before you follow the URL (again, presuming an HTTP URL) in the Call-Info header - presumably because following arbitrary HTTP URLs can pose known security risks (downloading virus-laden applets, or maybe just annoying audio files). The text does not support a reading of Call-Info in which it is set as a result of the authentication process (as suggested by the account given below). Any resemblance between the two headers further breaks down when we begin to look at the functional behavior of RPID - when it is added, how screening operates, and so forth. The most important difference is that Call-Info entails no concept of trusted and untrusted networks which are most certainly entailed by the RPID header. The use of the RPID header is predicated on the configuration of a set of 'trusted' destinations which can inspect the RPID header, and the assumption that it must be removed if it is transferred to an untrusted entity. Personally, I don't think Call-Info requires any such concept if it is used as the spec seems to intend. The argument that Call-Info is a subset of RPID I also find a little troublesome - when properly configured quite a few SIP headers, including at least To and From, could be represented by RPID. With the current extensibility mechanism in sip-privacy-04 I have no doubt it could be argued that RPID should replace all other means of asserting identity in SIP. Personally, I believe this is a defect of sip-privacy-04 rather than a strength. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Wednesday, March 27, 2002 2:19 PM > To: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > In all the criticism and discussion of draft-ietf-sip-privacy, there > has been one fact conveniently overlooked - the facilities already > in bis-09. I find them scary. > > When a UAC sends an INVITE and is challenged by a proxy, and responds > with the authentication credentials, the proxy has ascertained the > identity of the UAC. The proxy can then add a "Call-Info" header > to the INVITE that contains whatever identity information it wants. > See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED > that a UA only render the information in the Call-Info header field if > it can verify the authenticity of the element that originated the > header field and trusts that element." How? No clue is given. > > Note that with "Call-Info" headers can appear in both requests > and responses, and may be used by the UAC/UAS for presentation, > there are *no* restrictions on what this information could be, *no* > restrictions on how far it is propagated, *no* requirement that it > be encrypted, and *no* mechanism for the UAC/UAS to request that this > not be done. > > In that sense, draft-ietf-sip-privacy *really* is about privacy. > It includes a mechanism whereby the UAC can request that its > identity be kept private and that proxies NOT include information > (which the proxies will obtain and know) in the message that is > forwarded to the destination. The entire rest of the draft deals > with the consequences of this request. > > I find it very surprising that an attempt to restrict the use of the > Call-Info header (thereby requiring a new header name, Remote-Party-ID) > is meeting with such objection, when there was absolutely no comment > on the Call-Info usage (and no applicability statement attached to it) > during the WGLC or AD review of 2543bis. > > From a service provider point of view, I'm not sure I see a difference > between requiring certain proxy behavior with respect to the "Call-Info" > headers, than requiring the same proxy behavior with "Remote-Party-ID" > headers. Codifing the requirements would be useful in either case; > and doing this with purchase orders is likely not the best way to do > this. > > However, I do believe Remote-Party-ID is more general than Call-Info, > and solves a bigger piece of the problem. While sufficient > mechanism exists in bis-09 to do CLIP/CLIR through the use of > Call-Info headers, it is without the ability of the UAC/UAS to know > that its anonymity request will be honored (presumably signaled through > use of "Anonymous" in the display-name of the From header). > > Better trust that proxy when you send the Authorization information. > > Bill Marshall > wtm@research.att.com > > -----original message----- > Date: Wed, 27 Mar 2002 12:08:45 -0800 > To: Flemming Andreasen > From: Matt Holdrege > Subject: Re: [Sip] Comment, SIP Privacy draft > Cc: Dean Willis , sip@ietf.org > > At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > > Matt Holdrege wrote: > > > You can work on the > > > more general case and I fully support that. But some of > us still care about > > > interworking with the PSTN and we need to get that bit > specified ASAP > > > before the world is polluted with proprietary SIP headers. > > > >If that's all you want it's pretty easy: Just add an ISUP > body to all > >your SIP > >messages and fill in the blanks. However some of us were hoping for > >something a > >little more general and useful. > > No, we actually need the Remote Party ID and restricted flag. > I also hope > for a more general and useful way to deal with privacy. But > it seems like > that's going to be a difficult sell or at least a longer term > project than > originally expected. So it would be nice to get something > less out the door > now so that Service Providers can use it today, and the ITU-T > and 3GPP > won't go off and do something to the SIP headers that the > IETF doesn't support. > -----other original message----- From: "Peterson, Jon" To: "'Mark Watson'" , "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:27:00 -0600 A few more things about this Call-Info business. Firstly, nothing in the SIP standard that I'm aware of suggests that there would be some sort of telephony service based on the proxy insertion of Call-Info. As far as I know Call-Info is not intended to be an identity-assertion mechanism. Agreed that the spec does not rule out proxy servers adding the header, but at the same time the spec doesn't suggest any conditions under which proxies could or should add Call-Info. Call-Info clearly exists for a purpose unrelated to privacy/identity management, although I concede that its intended use may have its own privacy implications. But do your concerns about the legality of publically available services extend to instant messaging, Internet gaming, and the like? I'd further note that I'm not sure that it is the responsibility of each SIP header to provide its own mechanism by which a UA can specify whether or not they would like the header to be added or modified by proxy servers. Rather, I think a request by the end user for privacy from the network should apply to any headers that would potentially divulge private information. So in other words, I think that a mechanism comparable to the RPID-Privacy header in sip-privacy-04 should allow a UA to specify how the network should deal with their private identity information, regardless of the header in which that information appears (including From, Call-Info, or what have you). On another matter, note that sip-privacy-04 provides no mechanism that allows the recipient of messages to authenticate the party that added a particular header - sip-privacy only ensures that some 'trusted' entity, rather than an untrusted entity, has added a screened RPID. The only SIP headers I'm aware of that contain cryptographic authentication are described in the Digest section of bis09 - headers of this form allow one to ascertain the identity of the party that generated the header. RPID assumes some out-of-band mechanism by which an authenticated identity is discovered which is in turn persisted in the RPID header. I'd therefore say that RPID offers no improvement on Call-Info with regard to identifying the party that added the header. I might also add that I for one have not particularly howled about the lack of this feature (it would be nice as a general property of SIP headers, like for Via, but this isn't in the scope of this priblem). I'm only howling about the use of RPID outside the context of network-verified identity in support of privacy. Jon Peterson NeuStar, Inc. -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, March 28, 2002 6:08 AM To: 'William Marshall'; sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Must say I hadn't spotted this - Bill makes some very good points. It's worth noting that it would not be legal in most places to build a publically available service based on proxy insertion of the Call-Info. There is no way for the user to indicate on a call by call basis whether the proxy should insert the Call-Info or not. This capability would be required to have this as part of a publically available service, even if you do have a trust relationship with your home proxy etc. etc. The bis-09 text implies that proxies could insert this field but makes no statements to warn service designers about the legal minefield they would thus be entering. Very unfortunate when a single Call-Info-Restriction indicator would have solved the problem. It was exactly statements about needing to 'verify the authenticity of the element that originated the header field and trust that element' which have generated howls of protest over Remote-Party-ID, even though the RPID draft always described the trust model within which this was possible. How exactly *can* you determine who added a particular header and whether you trust them, outside of the type of scenario described in the RPID draft? Perhaps we should deprecate Call-Info immediately and replace it with Remote-Party-ID? ...Mark _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 09:04:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14135 for ; Fri, 29 Mar 2002 09:04:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08248 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 09:04:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06940; Fri, 29 Mar 2002 08:47:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06910 for ; Fri, 29 Mar 2002 08:47:17 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13045 for ; Fri, 29 Mar 2002 08:47:13 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TDkjY29879; Fri, 29 Mar 2002 05:46:45 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23506; Fri, 29 Mar 2002 05:46:32 -0800 (PST) Message-ID: <3CA46FB7.A1AC67C2@cisco.com> Date: Fri, 29 Mar 2002 08:44:23 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Mark Watson'" , "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A4@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > A few more things about this Call-Info business. > > Firstly, nothing in the SIP standard that I'm aware of suggests that there > would be some sort of telephony service based on the proxy insertion of > Call-Info. As far as I know Call-Info is not intended to be an > identity-assertion mechanism. Agreed that the spec does not rule out proxy > servers adding the header, but at the same time the spec doesn't suggest any > conditions under which proxies could or should add Call-Info. So a draft that specified this, one way or the other, would be perfectly legit. > Call-Info > clearly exists for a purpose unrelated to privacy/identity management, > although I concede that its intended use may have its own privacy > implications. But do your concerns about the legality of publically > available services extend to instant messaging, Internet gaming, and the > like? > > I'd further note that I'm not sure that it is the responsibility of each SIP > header to provide its own mechanism by which a UA can specify whether or not > they would like the header to be added or modified by proxy servers. Rather, > I think a request by the end user for privacy from the network should apply > to any headers that would potentially divulge private information. So in > other words, I think that a mechanism comparable to the RPID-Privacy header > in sip-privacy-04 should allow a UA to specify how the network should deal > with their private identity information, regardless of the header in which > that information appears (including From, Call-Info, or what have you). > I think we have all agreed on this point as far as the general SIP privacy story goes. How you ensure that this actually happens without some kind of "trust" somewhere is another story. > > On another matter, note that sip-privacy-04 provides no mechanism that > allows the recipient of messages to authenticate the party that added a > particular header - sip-privacy only ensures that some 'trusted' entity, > rather than an untrusted entity, has added a screened RPID. We have been over this issue numerous times. Authenticity is a general SIP problem that should not be solved by each individual header. There is supposed to be a general SIP security solution that can solve this problem and once it does, it can provide true authenticity for the Remote-Party-Id header as well. > The only SIP > headers I'm aware of that contain cryptographic authentication are described > in the Digest section of bis09 - headers of this form allow one to ascertain > the identity of the party that generated the header. RPID assumes some > out-of-band mechanism by which an authenticated identity is discovered which > is in turn persisted in the RPID header. I'd therefore say that RPID offers > no improvement on Call-Info with regard to identifying the party that added > the header. Very true, however I repeat: A general security problem should have a general security solution. I thought we already had consensus on this. > I might also add that I for one have not particularly howled > about the lack of this feature (it would be nice as a general property of > SIP headers, like for Via, but this isn't in the scope of this priblem). I'm > only howling about the use of RPID outside the context of network-verified > identity in support of privacy. So to sum up. You are not opposed to having a header that can be misused (becuase then you would be opposed to the Call-Info header), but you want to make sure that people get some guidelines about appropriate header usage. Consequently, you should not be opposed to the Remote-Party-Id header and its procedures as currently defined, only the applicability statement in case it's not clear enough. However, that's clearly not the case, so what am I missing here ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 09:04:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14174 for ; Fri, 29 Mar 2002 09:04:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08287 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 09:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06895; Fri, 29 Mar 2002 08:46:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06870 for ; Fri, 29 Mar 2002 08:46:25 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13027 for ; Fri, 29 Mar 2002 08:46:20 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TDjqY29576; Fri, 29 Mar 2002 05:45:52 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23270; Fri, 29 Mar 2002 05:45:39 -0800 (PST) Message-ID: <3CA4674B.3CC79BA1@cisco.com> Date: Fri, 29 Mar 2002 08:08:27 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A2@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > A note on the paragraph below. > > First, I don't think that the applicability statement in sip-privacy is > intended to be an exhaustive list of requirements for the mechanism - quite > the opposite, it's a set of restrictions on the use of the mechanism. Our AD doesn't seem to agree with this. > The > need for these restrictions arose from the (concrete) ways in which the > mechanism was being applied. > > I don't actually believe that call trace, as I understand it, requires RPID > or any comparable apparatus in SIP signaling. No new protocol mechanism is > required for a proxy server to record the results of an authentication > (indexed perhaps by Call-ID) so that administrative requests for the > identity of the originator of a call can be satisfied. The philosophy behind all the DCS extensions and hence the privacy draft was to get state out of the network and into the endpoints. The way it's done in this case is by encrypting a private Remote-Party-Id before passing it to an untrusted entity. However, it is true that there are, as always, many different ways of solving a given problem, and if you are content with recording state in the network, then you are of course correct. But, I have a very big problem with having an applicability statement thrown in at the last minute that all of a sudden starts changing my design philosophy and goals and hence requires me to change the mechanism. > I think RPID actually > attempts something a little more ambitious; sharing this identity > information in a putatively secure fashion within a community of 'trusted' > servers, so that this private identity information is immediately available > to any 'trusted' element that inspects the signaling, although it is still > concealed from end users. The problem occurs when you want to forward the message to an untrusted entity, whether an end user or something else (e.g. another provider). > How the applicability statement hinders even this > goal, though, is unclear to me. All that the applicability statement > restricts is the insertion or receipt of RPID by untrusted elements. Surely > this is unrelated to call trace? In short, I doubt that the AS has made call > trace an impossible goal for the RPID header. See above. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 09:11:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14619 for ; Fri, 29 Mar 2002 09:11:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08430 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 09:11:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07055; Fri, 29 Mar 2002 08:47:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06939 for ; Fri, 29 Mar 2002 08:47:20 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13049 for ; Fri, 29 Mar 2002 08:47:16 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2TDkQI6017743; Fri, 29 Mar 2002 05:46:26 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA23381; Fri, 29 Mar 2002 05:46:03 -0800 (PST) Message-ID: <3CA46D28.2EED315@cisco.com> Date: Fri, 29 Mar 2002 08:33:28 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A3@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > It is true that the Call-Info header mechanism is a relatively > underspecified and open-ended way of inserting some information, possibly > information that could reveal an identity, into SIP messages. If one reads > the spec with an open mind, one could construe the Call-Info header as a way > that a proxy server could insert an identity on behalf of the sender of a > message. OK - so we agree that Call-Info duplicates Remote-Party-Id functionality as far as this point is concerned. All we need is someone specifying the usage. > In that respect it could be argued (though I think it's a bit of a > stretch) that there is arbitrary network-asserted 'identity' information > floating around in bis09 that has no adequate authentication or privacy > story. Bill is certainly right to assert that many things are underspecified > in the SIP family of standards, and that it is dangerous to throw > applicability statements when you live in glass houses. It certainly is - surely there is no double standard here ? > > Should there be a mechanism in SIP that allows a user agent to suggest that > proxies treat their requests privately? Of course. I think the presence of > some sort of privacy flag/header in requests is a reasonable way to do so > (vide the RPID-Privacy header in sip-privacy today). Guaranteeing privacy > entails managing a number of headers that could potentially divulge identity > - Call-Info is one of many examples (the open-ended User-Agent and Server > headers could also be used as repositories for potentially private data, let > alone common headers like Via and Contact). Indeed they could, just like a Remote-Party-Id header can be used in ways people did not intend to. But why is it, that this must be obstructed at all cost in the privacy-draft case, but it's perfectly legit in the SIP spec ? In fact, if I rewrote the privacy-draft to use Call-Info instead of Remote-Party-Id, what would your arguments now be ? > I think that the general privacy > story for SIP needs to account for restricting the presentation of data that > might appear in any of these headers. The final version of a privacy draft > in the SIP WG, IMHO, should answer all these risks. When I request privacy > from the network, if the network supports this privacy capability, it should > be mindful of the Call-Info header. We can agree on that as long as we keep in mind, that the privacy-04 draft is not the final SIP privacy story. > > All that said, I feel that it is somewhat misleading to suggest that > Call-Info and RPID actually have a similar function, or more directly, that > Call-Info should in fact be replaced with RPID. Well, I would actually argue the other way. Let's drop Remote-Party-Id and just use Call-Info since nobody can object to that. > The note below actually > suggests Call-Info could be used to implement a CLIP/CLIR service - suffice > it to say I do not believe this was the intention behind 20.9 in bis09. Ahh, but it could be used in that way - why is there not an applicability statement to make sure it can't be misused ? > > Call-Info is intended to be a way to display optional content to the > recipient of a message referenced by something like HTTP URIs. > Remote-Party-ID, as far as I can make out, is intended to be a repository > for a network-verified SIP URI designating the identity of a party in a > session. Prima facie these do not seem co-extensive. Personally, I would be > happy to see Call-Info specified in more detail in the standard, and > significantly limited in the process. For example, I'm not aware of the > motivation to allow proxies to add Call-Info, and on initial reflection that > doesn't seem indispensible. I have not exactly found the proponents of RPID > to be similarly accomodating. > > A few specific points on the analogy between Call-Info and RPID. First of > all, section 20.9 does not suggest that the Call-Info carries identity > information (at least, not in the sense that the From or RPID header carries > an identity) - I suppose that the fact that Call-Info could carry any URI > means that the spec does not rule out carrying a SIP URI. But throughout bis > (including the sole example given in 20.9), this header is used to carry > HTTP URLs associated with the originator of the message. Second, to my > knowledge no examples are given in which Call-Info is set by a proxy server > - I acknowledge that the header can be modified by proxies, but 20.9 > suggests that Call-Info is predominantly managed by UAs. Third, nothing in > the text of 20.9 suggests that a Call-Info header will be populated as a > result of the authentication process. Well, why on earth are proxies allow to muck with it then ? Also, why does it talk about "trust that element" ? This all sounds very familiar to me. > Rather, the RECOMMENDED text cited > below merely suggests that you should know the identity of the sender of > this message before you follow the URL (again, presuming an HTTP URL) in the > Call-Info header - presumably because following arbitrary HTTP URLs can pose > known security risks (downloading virus-laden applets, or maybe just > annoying audio files). The text does not support a reading of Call-Info in > which it is set as a result of the authentication process (as suggested by > the account given below). > Hmm, I quote: "Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element." > Any resemblance between the two headers further breaks down when we begin to > look at the functional behavior of RPID - when it is added, how screening > operates, and so forth. The most important difference is that Call-Info > entails no concept of trusted and untrusted networks which are most > certainly entailed by the RPID header. The use of the RPID header is > predicated on the configuration of a set of 'trusted' destinations which can > inspect the RPID header, and the assumption that it must be removed if it is > transferred to an untrusted entity. Personally, I don't think Call-Info > requires any such concept if it is used as the spec seems to intend. > A couple of problems here. First of all the Call-Info talks about trust without specifying what that is. Secondly, you are talking about providing privacy for a Call-Info header which you agreed above would be valuable, so the part about "removing" before forwarding to untrusted entities ends up being the same (you agreed above that a generic privacy mechanism should cover Call-Info). Finally, Remote-Party-Id is not supposed to be removed when forwarded to an untrusted entity - it is supposed to be encrypted so we can do call trace. > > The argument that Call-Info is a subset of RPID I also find a little > troublesome - when properly configured quite a few SIP headers, including at > least To and From, could be represented by RPID. With the current > extensibility mechanism in sip-privacy-04 I have no doubt it could be argued > that RPID should replace all other means of asserting identity in SIP. > Personally, I believe this is a defect of sip-privacy-04 rather than a > strength. Yeah, nothing like the good old smokescreen. Nobody has suggested the above so let's leave this out - shall we ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 09:14:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14813 for ; Fri, 29 Mar 2002 09:14:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08584 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 09:14:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07617; Fri, 29 Mar 2002 08:57:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07590 for ; Fri, 29 Mar 2002 08:57:54 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13686 for ; Fri, 29 Mar 2002 08:57:50 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 6CC0F1E092; Fri, 29 Mar 2002 08:57:53 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA07105; Fri, 29 Mar 2002 08:57:50 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA87684; Fri, 29 Mar 2002 08:57:16 -0500 (EST) Date: Fri, 29 Mar 2002 08:57:16 -0500 (EST) Message-Id: <200203291357.IAA87684@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jon Peterson wrote: > I don't actually believe that call trace, as I understand it, requires RPID > or any comparable apparatus in SIP signaling. No new protocol mechanism is > required for a proxy server to record the results of an authentication > (indexed perhaps by Call-ID) so that administrative requests for the > identity of the originator of a call can be satisfied. So to make an untraceable call, simply re-use the same From, To, and Call-ID values from the last call you received..... Or is it the job of the proxies to verify the global uniqueness of Call-ID? How much history information do you expect proxies to keep? The key question with call trace is, what (and how much) information does the UA need to keep, and to provide back to the administration system, in order to perform the trace. A full "message/sip" of the INVITE request? But that won't include the To-tag; so both the INVITE and the 200-OK final response to the INVITE? A huge request and a huge database, vs. a single header with all the info packaged up. Why is this not a no-brainer? Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'Flemming Andreasen'" , Dean Willis Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 02:02:51 -0600 A note on the paragraph below. First, I don't think that the applicability statement in sip-privacy is intended to be an exhaustive list of requirements for the mechanism - quite the opposite, it's a set of restrictions on the use of the mechanism. The need for these restrictions arose from the (concrete) ways in which the mechanism was being applied. I don't actually believe that call trace, as I understand it, requires RPID or any comparable apparatus in SIP signaling. No new protocol mechanism is required for a proxy server to record the results of an authentication (indexed perhaps by Call-ID) so that administrative requests for the identity of the originator of a call can be satisfied. I think RPID actually attempts something a little more ambitious; sharing this identity information in a putatively secure fashion within a community of 'trusted' servers, so that this private identity information is immediately available to any 'trusted' element that inspects the signaling, although it is still concealed from end users. How the applicability statement hinders even this goal, though, is unclear to me. All that the applicability statement restricts is the insertion or receipt of RPID by untrusted elements. Surely this is unrelated to call trace? In short, I doubt that the AS has made call trace an impossible goal for the RPID header. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, March 27, 2002 5:49 AM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > [snip] > > If the AS is trying to be a complete listing of requirements then it is > clearly deficient. Moreover, if this is indeed the intention with an > applicability statement, then it is very concerning, that we have this > applicability statement being forced into the document by our "spirit > guides" at the last minute without any discussion about the actual > requirements. As I mentioned before, call trace completely fell through the > cracks here essentially rendering the draft useless for what it was supposed > to do. As this discussion shows, there is disagreement on other points as > well. > > [snip] > > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 12:05:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23409 for ; Fri, 29 Mar 2002 12:05:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18013 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 12:05:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15599; Fri, 29 Mar 2002 11:44:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15569 for ; Fri, 29 Mar 2002 11:44:10 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21977 for ; Fri, 29 Mar 2002 11:44:05 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2TGhdU12171 for ; Fri, 29 Mar 2002 10:43:39 -0600 From: "Dean Willis" To: Date: Fri, 29 Mar 2002 10:43:05 -0600 Message-ID: <000101c1d740$cd1d8ff0$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Privacy or Caller-ID? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please take a look at http://search.ietf.org/internet-drafts/draft-ema-vpim-clid-03.txt This draft defines Caller-ID and Caller-Name headers that could be readily mapped into SIP. I suspect all it needs is a Caller-ID-Restriction header to be able to provide CLID-CLIR interowrking between PSTN and a closed SIP network. Comments? -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 12:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24479 for ; Fri, 29 Mar 2002 12:28:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19089 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 12:28:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18130; Fri, 29 Mar 2002 12:07:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18100 for ; Fri, 29 Mar 2002 12:07:53 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23660 for ; Fri, 29 Mar 2002 12:07:49 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2TH7MK19305; Fri, 29 Mar 2002 09:07:22 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA21044; Fri, 29 Mar 2002 09:07:21 -0800 (PST) Message-ID: <3CA49F3F.34D15725@cisco.com> Date: Fri, 29 Mar 2002 12:07:11 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Privacy or Caller-ID? References: <000101c1d740$cd1d8ff0$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > Please take a look at > > http://search.ietf.org/internet-drafts/draft-ema-vpim-clid-03.txt > > This draft defines Caller-ID and Caller-Name headers that could be > readily mapped into SIP. > > I suspect all it needs is a Caller-ID-Restriction header to be able to > provide CLID-CLIR interowrking between PSTN and a closed SIP network. > > Comments? > What problem are you trying to solve and what is the list of requirements that must be satisfied ? -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 12:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25511 for ; Fri, 29 Mar 2002 12:58:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20915 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 12:58:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19150; Fri, 29 Mar 2002 12:29:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19105 for ; Fri, 29 Mar 2002 12:29:09 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24504 for ; Fri, 29 Mar 2002 12:29:05 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id D9A671E162; Fri, 29 Mar 2002 12:28:37 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA10594; Fri, 29 Mar 2002 12:28:34 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id MAA20264; Fri, 29 Mar 2002 12:28:32 -0500 (EST) Date: Fri, 29 Mar 2002 12:28:32 -0500 (EST) Message-Id: <200203291728.MAA20264@fish.research.att.com> To: dwillis@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] Privacy or Caller-ID? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean Willis wrote: > Please take a look at > > http://search.ietf.org/internet-drafts/draft-ema-vpim-clid-03.txt > > This draft defines Caller-ID and Caller-Name headers that could be > readily mapped into SIP. > > I suspect all it needs is a Caller-ID-Restriction header to be able to > provide CLID-CLIR interowrking between PSTN and a closed SIP network. > > Comments? > It does need the Caller-ID-Restriction header, true. It also needs all the procedures described, telling how to do it. Are you seriously considering a draft with syntax but no procedures? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 13:10:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25992 for ; Fri, 29 Mar 2002 13:10:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21693 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 13:10:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20399; Fri, 29 Mar 2002 12:45:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20370 for ; Fri, 29 Mar 2002 12:44:58 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25102 for ; Fri, 29 Mar 2002 12:44:56 -0500 (EST) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2THiK802133; Fri, 29 Mar 2002 12:44:20 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 11:44:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A7@va02.va.neustar.com> From: "Peterson, Jon" To: "'William Marshall'" Cc: "'sip@ietf.org'" Subject: FW: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 11:44:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Whoops, an edit to that last note (pasted wrong version). Insert this into the middle. Jon Peterson NeuStar, Inc. ---- > So CLIP is easy. And it is certainly dangerous to presume a http URL, > when the spec contains no such limit. Well, let's talk about a reasonable interpretation. There are quite a few examples of the use of Call-Info in the sip spec, all of which use HTTP URLs. In fact, the 'minor functional changes' section says: o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users. The motivation for Call-Info is not identity carriage, anyway. The Call-Info header is a cousin of Alert-Info. Alert-Info is also proxy 'ar' in Table 2. It contains an example of an HTTP URL. That could also contains arbitrary URIs which could in turn be used to carry identity in place of traditional 'alerts'. Sure, the spec does not prevent Alert-Info from containing SIP URIs. But we all would agree that this isn't a good use of Alert-Info. I think it takes a relatively hostile reading of Call-Info to suggest that this is an appropriate usage. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 13:12:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26063 for ; Fri, 29 Mar 2002 13:12:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21759 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 13:12:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20043; Fri, 29 Mar 2002 12:37:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20001 for ; Fri, 29 Mar 2002 12:37:27 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24872 for ; Fri, 29 Mar 2002 12:37:24 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2THatZ16712; Fri, 29 Mar 2002 11:36:55 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 11:36:50 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A6@va02.va.neustar.com> From: "Peterson, Jon" To: "'William Marshall'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 11:36:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Well, I now believe that Flemming, Mark and I all read your original note about Call-Info slightly differently. Some further notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, March 29, 2002 5:21 AM > To: jon.peterson@neustar.biz > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > > [snip] > > I don't think it takes much of an open mind in reading the > spec, since > (1) 20.9 says a proxy can insert a Call-Info header > (2) Table 2 says a proxy can add or concatenate the header > field if not present > (3) Table 2 says a proxy must be able to read the header field But I'll bet you are the first person to suggest that: (4) The proxy would insert a URL customized to the originating end user (5) Call-Info with an "info" parameter can contain a SIP URI (spec gives an example only of a web page URL) (6) That the identity expressed in a Call-Info in (5) could be at variance with other identities carried in the message (7) That under some circumstances Call-Info should be removed/obscured for privacy reasons (8) That there should be a way proxies that insert a Call-Info can indicate that untrusted end users should not be able to perceive that Call-Info I don't think these are possibilities that we considered. > > So it is clearly the intent of this header that the proxy be able to > insert it; the only question is under what conditions. Granted it > is underspecified, and inserting bad information is just as allowable > as inserting good information. But I think a reasonable interpretation > of the existing text in bis-09 is that a proxy inserts this header > as a result of the authentication exchange. As an example: > Call-Info: ;purpose=info > Call-Info: ;purpose=info > So CLIP is easy. And it is certainly dangerous to presume a http URL, > when the spec contains no such limit. Well, let's talk about a reasonable interpretation. There are quite a few examples of the use of Call-Info in the sip spec, all of which use HTTP URLs. In fact, the 'minor functional changes' section The Call-Info header is a cousin of Alert-Info. Alert-Info is also proxy 'ar' in Table 2. It contains an example of an HTTP URL. > > > The argument that Call-Info is a subset of RPID I also find a little > > troublesome ... > > There was no attempt to claim that Call-Info was a subset of RPID, rather > that the RPID is actually a set of restrictions on the allowable use > of Call-Info. RPID is a very restricted subset of Call-Info. Note that > Call-Info contains all the extensibility mechanisms as RPID. > To me it isn't really material whether you think RPID should be conflated into Call-Info or vice versa - the point I made is that they are not co-extensive, that they have two very different intentions (carrying identity around among trusted network elements versus displaying optional content to the end-user), and that it therefore doesn't make sense to congflate them. It also isn't correct that Call-Info contains all of the extensibility mechanisms of RPID. There's no rpi-pty-type equivalent, for one thing. Also, I read your note as suggesting that Call-Info needed all of the handling restrictions that currently apply to RPID. > And, in another message (also attached), Jon wrote: > > On another matter, note that sip-privacy-04 provides no mechanism that > > allows the recipient of messages to authenticate the party that added a > > particular header - sip-privacy only ensures that some 'trusted' entity, > > rather than an untrusted entity, has added a screened RPID. > > As has been answered many times, previous versions of the privacy draft > did include this, but it was removed in favor of a general (still to > be defined) mechanism usable for other headers, too. The extension > mechanisms was specifically designed to allow this authentication. You > can't both complain that it is there and complain that it isn't. > I was just arguing why Call-Info gets us no closer than RPID, since neither header provides any authentication info about the inserting party - I was not claiming that it was a defect of sip-privacy that it wanted for this authentication mechanism. In fact, the next line in the paragraph from which the above quote is taken says this plainly. > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Peterson, Jon" > To: "'William Marshall'" , sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > Date: Fri, 29 Mar 2002 02:12:36 -0600 > > It is true that the Call-Info header mechanism is a relatively > underspecified and open-ended way of inserting some > information, possibly > information that could reveal an identity, into SIP messages. > If one reads > the spec with an open mind, one could construe the Call-Info > header as a way > that a proxy server could insert an identity on behalf of the > sender of a > message. In that respect it could be argued (though I think > it's a bit of a > stretch) that there is arbitrary network-asserted 'identity' > information > floating around in bis09 that has no adequate authentication > or privacy > story. Bill is certainly right to assert that many things are > underspecified > in the SIP family of standards, and that it is dangerous to throw > applicability statements when you live in glass houses. > > Should there be a mechanism in SIP that allows a user agent > to suggest that > proxies treat their requests privately? Of course. I think > the presence of > some sort of privacy flag/header in requests is a reasonable > way to do so > (vide the RPID-Privacy header in sip-privacy today). > Guaranteeing privacy > entails managing a number of headers that could potentially > divulge identity > - Call-Info is one of many examples (the open-ended > User-Agent and Server > headers could also be used as repositories for potentially > private data, let > alone common headers like Via and Contact). I think that the > general privacy > story for SIP needs to account for restricting the > presentation of data that > might appear in any of these headers. The final version of a > privacy draft > in the SIP WG, IMHO, should answer all these risks. When I > request privacy > from the network, if the network supports this privacy > capability, it should > be mindful of the Call-Info header. > > All that said, I feel that it is somewhat misleading to suggest that > Call-Info and RPID actually have a similar function, or more > directly, that > Call-Info should in fact be replaced with RPID. The note > below actually > suggests Call-Info could be used to implement a CLIP/CLIR > service - suffice > it to say I do not believe this was the intention behind 20.9 > in bis09. > Call-Info is intended to be a way to display optional content to the > recipient of a message referenced by something like HTTP URIs. > Remote-Party-ID, as far as I can make out, is intended to be > a repository > for a network-verified SIP URI designating the identity of a > party in a > session. Prima facie these do not seem co-extensive. > Personally, I would be > happy to see Call-Info specified in more detail in the standard, and > significantly limited in the process. For example, I'm not > aware of the > motivation to allow proxies to add Call-Info, and on initial > reflection that > doesn't seem indispensible. I have not exactly found the > proponents of RPID > to be similarly accomodating. > > A few specific points on the analogy between Call-Info and > RPID. First of > all, section 20.9 does not suggest that the Call-Info carries identity > information (at least, not in the sense that the From or RPID > header carries > an identity) - I suppose that the fact that Call-Info could > carry any URI > means that the spec does not rule out carrying a SIP URI. But > throughout bis > (including the sole example given in 20.9), this header is > used to carry > HTTP URLs associated with the originator of the message. Second, to my > knowledge no examples are given in which Call-Info is set by > a proxy server > - I acknowledge that the header can be modified by proxies, but 20.9 > suggests that Call-Info is predominantly managed by UAs. > Third, nothing in > the text of 20.9 suggests that a Call-Info header will be > populated as a > result of the authentication process. Rather, the RECOMMENDED > text cited > below merely suggests that you should know the identity of > the sender of > this message before you follow the URL (again, presuming an > HTTP URL) in the > Call-Info header - presumably because following arbitrary > HTTP URLs can pose > known security risks (downloading virus-laden applets, or maybe just > annoying audio files). The text does not support a reading of > Call-Info in > which it is set as a result of the authentication process (as > suggested by > the account given below). > > Any resemblance between the two headers further breaks down > when we begin to > look at the functional behavior of RPID - when it is added, > how screening > operates, and so forth. The most important difference is that > Call-Info > entails no concept of trusted and untrusted networks which are most > certainly entailed by the RPID header. The use of the RPID header is > predicated on the configuration of a set of 'trusted' > destinations which can > inspect the RPID header, and the assumption that it must be > removed if it is > transferred to an untrusted entity. Personally, I don't think > Call-Info > requires any such concept if it is used as the spec seems to intend. > > The argument that Call-Info is a subset of RPID I also find a little > troublesome - when properly configured quite a few SIP > headers, including at > least To and From, could be represented by RPID. With the current > extensibility mechanism in sip-privacy-04 I have no doubt it > could be argued > that RPID should replace all other means of asserting identity in SIP. > Personally, I believe this is a defect of sip-privacy-04 rather than a > strength. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Wednesday, March 27, 2002 2:19 PM > > To: sip@ietf.org > > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > > In all the criticism and discussion of draft-ietf-sip-privacy, there > > has been one fact conveniently overlooked - the facilities already > > in bis-09. I find them scary. > > > > When a UAC sends an INVITE and is challenged by a proxy, > and responds > > with the authentication credentials, the proxy has ascertained the > > identity of the UAC. The proxy can then add a "Call-Info" header > > to the INVITE that contains whatever identity information it wants. > > See Section 20.9 of 2543bis-09. As for the UAS, "It is RECOMMENDED > > that a UA only render the information in the Call-Info > header field if > > it can verify the authenticity of the element that originated the > > header field and trusts that element." How? No clue is given. > > > > Note that with "Call-Info" headers can appear in both requests > > and responses, and may be used by the UAC/UAS for presentation, > > there are *no* restrictions on what this information could be, *no* > > restrictions on how far it is propagated, *no* requirement that it > > be encrypted, and *no* mechanism for the UAC/UAS to request > that this > > not be done. > > > > In that sense, draft-ietf-sip-privacy *really* is about privacy. > > It includes a mechanism whereby the UAC can request that its > > identity be kept private and that proxies NOT include information > > (which the proxies will obtain and know) in the message that is > > forwarded to the destination. The entire rest of the draft deals > > with the consequences of this request. > > > > I find it very surprising that an attempt to restrict the use of the > > Call-Info header (thereby requiring a new header name, > Remote-Party-ID) > > is meeting with such objection, when there was absolutely no comment > > on the Call-Info usage (and no applicability statement > attached to it) > > during the WGLC or AD review of 2543bis. > > > > From a service provider point of view, I'm not sure I see a > difference > > between requiring certain proxy behavior with respect to > the "Call-Info" > > headers, than requiring the same proxy behavior with > "Remote-Party-ID" > > headers. Codifing the requirements would be useful in either case; > > and doing this with purchase orders is likely not the best > way to do > > this. > > > > However, I do believe Remote-Party-ID is more general than > Call-Info, > > and solves a bigger piece of the problem. While sufficient > > mechanism exists in bis-09 to do CLIP/CLIR through the use of > > Call-Info headers, it is without the ability of the UAC/UAS to know > > that its anonymity request will be honored (presumably > signaled through > > use of "Anonymous" in the display-name of the From header). > > > > Better trust that proxy when you send the Authorization information. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > Date: Wed, 27 Mar 2002 12:08:45 -0800 > > To: Flemming Andreasen > > From: Matt Holdrege > > Subject: Re: [Sip] Comment, SIP Privacy draft > > Cc: Dean Willis , sip@ietf.org > > > > At 11:57 AM 3/27/2002, Flemming Andreasen wrote: > > > Matt Holdrege wrote: > > > > You can work on the > > > > more general case and I fully support that. But some of > > us still care about > > > > interworking with the PSTN and we need to get that bit > > specified ASAP > > > > before the world is polluted with proprietary SIP headers. > > > > > >If that's all you want it's pretty easy: Just add an ISUP > > body to all > > >your SIP > > >messages and fill in the blanks. However some of us were > hoping for > > >something a > > >little more general and useful. > > > > No, we actually need the Remote Party ID and restricted flag. > > I also hope > > for a more general and useful way to deal with privacy. But > > it seems like > > that's going to be a difficult sell or at least a longer term > > project than > > originally expected. So it would be nice to get something > > less out the door > > now so that Service Providers can use it today, and the ITU-T > > and 3GPP > > won't go off and do something to the SIP headers that the > > IETF doesn't support. > > > > -----other original message----- > From: "Peterson, Jon" > To: "'Mark Watson'" , > "'William Marshall'" , sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > Date: Fri, 29 Mar 2002 02:27:00 -0600 > > A few more things about this Call-Info business. > > Firstly, nothing in the SIP standard that I'm aware of > suggests that there > would be some sort of telephony service based on the proxy > insertion of > Call-Info. As far as I know Call-Info is not intended to be an > identity-assertion mechanism. Agreed that the spec does not > rule out proxy > servers adding the header, but at the same time the spec > doesn't suggest any > conditions under which proxies could or should add Call-Info. > Call-Info > clearly exists for a purpose unrelated to privacy/identity management, > although I concede that its intended use may have its own privacy > implications. But do your concerns about the legality of publically > available services extend to instant messaging, Internet > gaming, and the > like? > > I'd further note that I'm not sure that it is the > responsibility of each SIP > header to provide its own mechanism by which a UA can specify > whether or not > they would like the header to be added or modified by proxy > servers. Rather, > I think a request by the end user for privacy from the > network should apply > to any headers that would potentially divulge private > information. So in > other words, I think that a mechanism comparable to the > RPID-Privacy header > in sip-privacy-04 should allow a UA to specify how the > network should deal > with their private identity information, regardless of the > header in which > that information appears (including From, Call-Info, or what > have you). > > On another matter, note that sip-privacy-04 provides no mechanism that > allows the recipient of messages to authenticate the party > that added a > particular header - sip-privacy only ensures that some > 'trusted' entity, > rather than an untrusted entity, has added a screened RPID. > The only SIP > headers I'm aware of that contain cryptographic > authentication are described > in the Digest section of bis09 - headers of this form allow > one to ascertain > the identity of the party that generated the header. RPID assumes some > out-of-band mechanism by which an authenticated identity is > discovered which > is in turn persisted in the RPID header. I'd therefore say > that RPID offers > no improvement on Call-Info with regard to identifying the > party that added > the header. I might also add that I for one have not > particularly howled > about the lack of this feature (it would be nice as a general > property of > SIP headers, like for Via, but this isn't in the scope of > this priblem). I'm > only howling about the use of RPID outside the context of > network-verified > identity in support of privacy. > > Jon Peterson > NeuStar, Inc. > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: Thursday, March 28, 2002 6:08 AM > To: 'William Marshall'; sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > > Must say I hadn't spotted this - Bill makes some very good points. > > It's worth noting that it would not be legal in most places to build a > publically available service based on proxy insertion of the > Call-Info. > There is no way for the user to indicate on a call by call > basis whether the > proxy should insert the Call-Info or not. This capability > would be required > to have this as part of a publically available service, even > if you do have > a trust relationship with your home proxy etc. etc. > > The bis-09 text implies that proxies could insert this field > but makes no > statements to warn service designers about the legal > minefield they would > thus be entering. Very unfortunate when a single Call-Info-Restriction > indicator would have solved the problem. > > It was exactly statements about needing to 'verify the > authenticity of the > element that originated the header field and trust that > element' which have > generated howls of protest over Remote-Party-ID, even though > the RPID draft > always described the trust model within which this was possible. > > How exactly *can* you determine who added a particular header > and whether > you trust them, outside of the type of scenario described in > the RPID draft? > > Perhaps we should deprecate Call-Info immediately and replace it with > Remote-Party-ID? > > ...Mark > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 13:48:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27894 for ; Fri, 29 Mar 2002 13:48:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24197 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 13:48:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22166; Fri, 29 Mar 2002 13:21:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22138 for ; Fri, 29 Mar 2002 13:21:10 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26355 for ; Fri, 29 Mar 2002 13:21:07 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TIKXY10273; Fri, 29 Mar 2002 10:20:33 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA19535; Fri, 29 Mar 2002 10:20:32 -0800 (PST) Message-ID: <3CA4B066.3CDB6B1C@cisco.com> Date: Fri, 29 Mar 2002 13:20:22 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , "'sip@ietf.org'" Subject: Re: FW: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A7@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > Whoops, an edit to that last note (pasted wrong version). Insert this into > the middle. > > Jon Peterson > NeuStar, Inc. > > ---- > > > So CLIP is easy. And it is certainly dangerous to presume a http URL, > > when the spec contains no such limit. > > Well, let's talk about a reasonable interpretation. There are quite a few > examples of the use of Call-Info in the sip spec, all of which use HTTP > URLs. In fact, the 'minor functional changes' section says: > > o Added the Alert-Info, Error-Info, and Call-Info header fields > for optional content presentation to users. > > The motivation for Call-Info is not identity carriage, anyway. > > The Call-Info header is a cousin of Alert-Info. Alert-Info is also proxy > 'ar' in Table 2. It contains an example of an HTTP URL. That could also > contains arbitrary URIs which could in turn be used to carry identity in > place of traditional 'alerts'. Sure, the spec does not prevent Alert-Info > from containing SIP URIs. But we all would agree that this isn't a good use > of Alert-Info. > > I think it takes a relatively hostile reading of Call-Info to suggest that > this is an appropriate usage. > No more hostile than to suggest that Remote-Party-Id is for user-asserted identity, when both the title, applicability statement and the text throughout specifically says that the draft does not deal with user authentication. The fact that Remote-Party-Id *can* be used for this is another story, just like Call-Info *can* be used for this. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 13:57:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28213 for ; Fri, 29 Mar 2002 13:57:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA24546 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 13:58:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23096; Fri, 29 Mar 2002 13:32:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23055 for ; Fri, 29 Mar 2002 13:32:16 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27147 for ; Fri, 29 Mar 2002 13:32:13 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TIVbY18249; Fri, 29 Mar 2002 10:31:39 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA29124; Fri, 29 Mar 2002 10:31:35 -0800 (PST) Message-ID: <3CA4B2FD.F76B1276@cisco.com> Date: Fri, 29 Mar 2002 13:31:25 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A6@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > > > So it is clearly the intent of this header that the proxy be able to > > insert it; the only question is under what conditions. Granted it > > is underspecified, and inserting bad information is just as allowable > > as inserting good information. But I think a reasonable interpretation > > of the existing text in bis-09 is that a proxy inserts this header > > as a result of the authentication exchange. As an example: > > Call-Info: ;purpose=info > > Call-Info: ;purpose=info > > So CLIP is easy. And it is certainly dangerous to presume a http URL, > > when the spec contains no such limit. > > Well, let's talk about a reasonable interpretation. There are quite a few > examples of the use of Call-Info in the sip spec, all of which use HTTP > URLs. Oh please - the privacy-draft has statements throughout saying it is not for user-asserted identity and that it doesn't even deal with user authentication, but that's apparently still not good enough since somebody could choose to use it this way. What's good for the goose is good for the gander. > > It also isn't correct that Call-Info contains all of the extensibility > mechanisms of RPID. On the contrary - the production for info-param allows for unlimited extensibility via generic-param. -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:01:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28440 for ; Fri, 29 Mar 2002 14:01:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25247 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:01:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23204; Fri, 29 Mar 2002 13:35:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23173 for ; Fri, 29 Mar 2002 13:35:07 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27234 for ; Fri, 29 Mar 2002 13:35:04 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2TIXWZ18623; Fri, 29 Mar 2002 12:33:32 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 12:33:27 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A8@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 12:33:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A few notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 5:33 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > "Peterson, Jon" wrote: > [snip] > > OK - so we agree that Call-Info duplicates Remote-Party-Id functionality as far > as this point is concerned. All we need is someone specifying the usage. > I really hope we all agree that the "proposal" Bill made to conflate RPID and Call-Info was not serious, but was intended to make a point about underspecification in the SIP spec, and also to illustrate that Call-Info has its own privacy implications. Right? I think it would be problematic to suggest that the Call-Info and RPID should be conflated, as the remainder of my note bears out. [snip] > > > > > Should there be a mechanism in SIP that allows a user agent > to suggest that > > proxies treat their requests privately? Of course. I think > the presence of > > some sort of privacy flag/header in requests is a > reasonable way to do so > > (vide the RPID-Privacy header in sip-privacy today). > Guaranteeing privacy > > entails managing a number of headers that could potentially > divulge identity > > - Call-Info is one of many examples (the open-ended > User-Agent and Server > > headers could also be used as repositories for potentially > private data, let > > alone common headers like Via and Contact). > > Indeed they could, just like a Remote-Party-Id header can be used in ways people > did not intend to. But why is it, that this must be obstructed at all cost in > the privacy-draft case, but it's perfectly legit in the SIP spec ? In fact, if I > rewrote the privacy-draft to use Call-Info instead of Remote-Party-Id, what > would your arguments now be ? > To limit the scope of the Call-Info, since the Call-Info is not intended to be an network-verified identity carriage parameter. Of course. This is not 'legit' in the SIP spec. We all know that in the two-hundred-odd pages of the SIP spec there are many remaining nits and gotchas, even when one is not reading the text in bad faith. This is clearly a bad faith reading of 20.9. No one would honestly believe that Call-Info is intended as a network-verified identitiy carriage mechanism. If that were proposed, I believe the authors of bis09 would say that was not a correct usage. The real, material difference here is that people want to do Bad Things with RPID, and RPID has broadened its definition and its mechanism to accomodate these things in the name of privacy. Call-Info is merely underspecified. > > > > All that said, I feel that it is somewhat misleading to suggest that > > Call-Info and RPID actually have a similar function, or more directly, that > > Call-Info should in fact be replaced with RPID. > > Well, I would actually argue the other way. Let's drop Remote-Party-Id and just > use Call-Info since nobody can object to that. > I can object, and I would. Why would anyone fail to object to that usage? > > The note below actually > > suggests Call-Info could be used to implement a CLIP/CLIR service - suffice > > it to say I do not believe this was the intention behind 20.9 in bis09. > > Ahh, but it could be used in that way - why is there not an applicability > statement to make sure it can't be misused ? > Although I already said this above, it is worth reiterating that RPID purports to be a privacy mechanism, but it has been earmarked for use in a number of ways that reflect poorly on privacy. [snip differences between RPID and Call-Info] > > Well, why on earth are proxies allow to muck with it then ? Also, why does it > talk about "trust that element" ? This all sounds very familiar to me. > To your first question, I dunno, actually. I mean, I guess I could see cases where a service provider wanted to add their homepage HTTP URI to a request as it passed as a kind free advertising. Really, those are the only sorts of cases I can imagine. To you second question, if you get an email from someone that you don't know which contains an HTTP URL, should you follow that URL? No, it could lead you somewhere you don't want to go, or worse, download some malicious software. This is all that "trust that element" note is saying. People have really chosen to read that in a hostile way. [snip] > > > > Hmm, I quote: > > "Therefore, it is RECOMMENDED that a UA only render the information in the > Call-Info header field if it can verify the authenticity of the element that > originated the header field and trusts that element." > And your quotation here supports what position, exactly? The account I gave above of why you shouldn't follow arbitrary URLs was the motivation for this text, as far as I remember, and I read this as consistent with the above. > > > > Any resemblance between the two headers further breaks down when we begin to > > look at the functional behavior of RPID - when it is added, how screening > > operates, and so forth. The most important difference is that Call-Info > > entails no concept of trusted and untrusted networks which are most > > certainly entailed by the RPID header. The use of the RPID header is > > predicated on the configuration of a set of 'trusted' destinations which can > > inspect the RPID header, and the assumption that it must be removed if it is > > transferred to an untrusted entity. Personally, I don't think Call-Info > > requires any such concept if it is used as the spec seems to intend. > > > > A couple of problems here. First of all the Call-Info talks about trust without > specifying what that is. Secondly, you are talking about providing privacy for a > Call-Info header which you agreed above would be valuable, so the part about > "removing" before forwarding to untrusted entities ends up being the same (you > agreed above that a generic privacy mechanism should cover Call-Info). Finally, > Remote-Party-Id is not supposed to be removed when forwarded to an untrusted > entity - it is supposed to be encrypted so we can do call trace. > It's clear to me, anyway, that the 'trust' here is unrelated to the 'trusted network' concept in RPID. For one thing, the trust of Call-Info is a matter of human oversight. In much the same way that you choose to follow a URL in an email or not, you can choose to follow the URL in a Call-Info - this URL is intended to be consumed by humans. This is radically different than the identity in an RPID. Automatons (proxies) need to decide programmatically whether or not they "trust" the next hop to which they are sending signaling, and groom the RPIDs in messages appropriately. These two forms of trust are quite different. I see Call-Info as one of many ways that potentially private information could be communicated inadvertantly to an end user, so in that sense I agree it is valuable for the general SIP privacy mechanism to discuss Call-Info. However, I don't think Call-Info should play a role in expressing a network-verified identity of end-users. sip-privacy-04 says 'encrypt or remove', yes. But not enough information about encyrption is provided for that to be a viable option - this isn't entirely the privacy draft's fault, but sip-privacy-04 could have said more than it does, anyway. It is also not clear to me how 'encryption' helps call trace. Encryption would only be relevant to call trace in so far as all entities that will be able to decrypt the RPIDs are trusted, and that trusted elements encrypt the RPIDs so that they can pass through untrusted entities on the way to some other trusted entity. Encryption doesn't really make decisions about trust any easier (which key do I to encrypt RPIDs when I send them to an untrusted source? how do I know where the signaling will eventually end up?), it just pushes the problem around. > > > > > The argument that Call-Info is a subset of RPID I also find a little > > troublesome - when properly configured quite a few SIP headers, including at > > least To and From, could be represented by RPID. With the current > > extensibility mechanism in sip-privacy-04 I have no doubt it could be argued > > that RPID should replace all other means of asserting identity in SIP. > > Personally, I believe this is a defect of sip-privacy-04 rather than a > > strength. > > Yeah, nothing like the good old smokescreen. Nobody has suggested the above so > let's leave this out - shall we ? I am trying to argue in good faith here - this is not meant to be deceptive, but rather just to illustrate that if you want to conflate RPID with Call-Info, there are quite a few other headers you could also choose to lump in with those two. It is dangerous to go down that path, I think. > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:26:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29690 for ; Fri, 29 Mar 2002 14:26:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26857 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:26:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25201; Fri, 29 Mar 2002 14:01:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25167 for ; Fri, 29 Mar 2002 14:01:23 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28416 for ; Fri, 29 Mar 2002 14:01:20 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2TJ0iZ19685; Fri, 29 Mar 2002 13:00:44 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 13:00:39 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701A9@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , "'sip@ietf.org'" Subject: RE: FW: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:00:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some further notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 10:20 AM > To: Peterson, Jon > Cc: 'William Marshall'; 'sip@ietf.org' > Subject: Re: FW: [Sip] Comment, SIP Privacy draft > [snip] > > > > I think it takes a relatively hostile reading of Call-Info to suggest that > > this is an appropriate usage. > > > > No more hostile than to suggest that Remote-Party-Id is for user-asserted > identity, when both the title, applicability statement and the text throughout > specifically says that the draft does not deal with user authentication. The > fact that Remote-Party-Id *can* be used for this is another story, just like > Call-Info *can* be used for this. > One huge difference is that the backers of the Call-Info header did not openly intend to use it for user-asserted identity (let alone any form of identity). In the case of RPID this is exemplified in sip-privacy-04 by the presence of the 'screen=' parameter. In the past, you've made the case that carrying around unverified, user-asserted identities is useful for RPID. This goes very much against the spirit of the AS. I fear that we're losing sight of the points that motivated this whole discussion (or more selfishly, my own involvement). I don't want to destroy sip-privacy-04. I want to see things like 'screen' removed so that the mechanism comes into parity with the applicability. If you honestly supported the sentiment you tout above, I believe you would have no problem removing 'screen'. To me this is all about bringing the mechanism into conformity with the applicability. I only entered into this fray because of the ways that RPID was proposed to be used, because a concrete case was raised in which a major customer of SIP wanted to abuse RPID and create serious interoperability concerns. I don't think this is a double standard - the squeaky wheel gets the grease, and RPID happened to be squeaking. While you and Bill have made a reasonable case that Call-Info as its syntax is described could theoretically be misinterpreted, to date I must point out that it hasn't been (outside of this little thought-experiment). If someone did put out an I-D proposing the use of Call-Info for things along these lines (for example, proposing a 'screen=' and 'privacy=' parameter for Call-Info, and then appropriate proxy handling for Call-Info in a 'trusted federation of networks'), I doubt it would pass WGLC. Why these Call-Info arguments should encourage us to proceed with sip-privacy-04 as it stands is mysterious to me. > -- Flemming > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:33:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00144 for ; Fri, 29 Mar 2002 14:33:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27490 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:33:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25450; Fri, 29 Mar 2002 14:03:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25413 for ; Fri, 29 Mar 2002 14:03:45 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28531 for ; Fri, 29 Mar 2002 14:03:41 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2TJ3DK25432; Fri, 29 Mar 2002 11:03:13 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13952; Fri, 29 Mar 2002 11:03:11 -0800 (PST) Message-ID: <3CA4BA66.C9ECE97A@cisco.com> Date: Fri, 29 Mar 2002 14:03:02 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A8@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Lots of snipping... "Peterson, Jon" wrote: > > [snip] > > > > OK - so we agree that Call-Info duplicates Remote-Party-Id functionality > as far > > as this point is concerned. All we need is someone specifying the usage. > > > > I really hope we all agree that the "proposal" Bill made to conflate RPID > and Call-Info was not serious, but was intended to make a point about > underspecification in the SIP spec, and also to illustrate that Call-Info > has its own privacy implications. Right? > No, we are actually quite serious. We have a problem that needs a solution, and if the privacy draft ends up dying or otherwise does not provide that solution very soon, we need an alternative. Since Call-Info is already spec'ed and we are low on alternatives, the choice is pretty clear. > I think it would be problematic to suggest that the Call-Info and RPID > should be conflated, as the remainder of my note bears out. > We can all agree it is not ideal, but we are given little choice. > This is not 'legit' in the SIP spec. We all know that in the two-hundred-odd > pages of the SIP spec there are many remaining nits and gotchas, even when > one is not reading the text in bad faith. This is clearly a bad faith > reading of 20.9. No one would honestly believe that Call-Info is intended as > a network-verified identitiy carriage mechanism. If that were proposed, I > believe the authors of bis09 would say that was not a correct usage. As far as bad-faith reading of specs is concerned, this is hardly the only example as I pointed out in previous e-mails. > > > > > > > All that said, I feel that it is somewhat misleading to suggest that > > > Call-Info and RPID actually have a similar function, or more directly, > that > > > Call-Info should in fact be replaced with RPID. > > > > Well, I would actually argue the other way. Let's drop Remote-Party-Id and > just > > use Call-Info since nobody can object to that. > > > > I can object, and I would. Why would anyone fail to object to that usage? You cannot object to using an already defined header in specific ways, regardless of whether it was intended to be used that way or not. > To you second question, if you get an email from someone that you don't know > which contains an HTTP URL, should you follow that URL? No, it could lead > you somewhere you don't want to go, or worse, download some malicious > software. I wish you would explain that to my HTML enabled e-mail reader, 'cause it sure doesn't work that way. > > I see Call-Info as one of many ways that potentially private information > could be communicated inadvertantly to an end user, so in that sense I agree > it is valuable for the general SIP privacy mechanism to discuss Call-Info. > However, I don't think Call-Info should play a role in expressing a > network-verified identity of end-users. > Neither do I, but I need an agreeable alternative, and I don't see that anywhere. > > sip-privacy-04 says 'encrypt or remove', yes. But not enough information > about encyrption is provided for that to be a viable option - this isn't > entirely the privacy draft's fault, but sip-privacy-04 could have said more > than it does, anyway. It is also not clear to me how 'encryption' helps call > trace. Encryption would only be relevant to call trace in so far as all > entities that will be able to decrypt the RPIDs are trusted, and that > trusted elements encrypt the RPIDs so that they can pass through untrusted > entities on the way to some other trusted entity. I think you have misunderstood how this aspect works. The encrypting entity is the one that will perform the decryption - the hostport identifies the encrypting proxy and hence normal SIP routing of requests with such a Request-URI solves your problem. > Encryption doesn't really > make decisions about trust any easier (which key do I to encrypt RPIDs when > I send them to an untrusted source? how do I know where the signaling will > eventually end up?), it just pushes the problem around. > Not really since you know that if there is a need to decrypt it (the call trace case), you will in fact get in back to where it was encrypted and hence there's no need to specify anything. If on the other hand you are talking about the general case of passing Remote-Party-Id around inside your trusted boundary, then I agree - the draft actually states that there are many unsolved issues here (which is the Proxy-Require option is in there). -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:43:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00484 for ; Fri, 29 Mar 2002 14:43:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA27929 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:43:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26542; Fri, 29 Mar 2002 14:21:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26491 for ; Fri, 29 Mar 2002 14:21:29 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29533 for ; Fri, 29 Mar 2002 14:21:25 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2TJKmZ20410; Fri, 29 Mar 2002 13:20:48 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 13:20:43 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701AA@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:20:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One more note here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 10:31 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > [snip] > > > > > It also isn't correct that Call-Info contains all of the extensibility > > mechanisms of RPID. > > On the contrary - the production for info-param allows for unlimited > extensibility via generic-param. Why pick on Call-Info? Any number of SIP parameters could be misinterpreted to contain identity info, especially because they happen to be extensible. Via has a generic-param extension as well, so we could propose an 'rpid=' Via parameter that replicates RPID there, which each entity that generates a Via should add. The point is that the RPID header is intended to be part of some identity/privacy assertion mechanism - that's its reason for existing, and that is why it is has attracted these applicability concerns. Via and Call-Info have a different purpose, which is why (to date) we haven't had any reason to worry over their applicability - to date, no one has bothered to formally propose an abusive application of their extensibility. But anyway, in the quote above I was just making the less ambitious and more specific point that 20.9 happens to state that the Call-Info characterizes the entity that originated the message, and that this would seem to argue against the inclusion of a rpi-pty-type parameter. > > -- Flemming > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:48:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00755 for ; Fri, 29 Mar 2002 14:48:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28067 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:48:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26363; Fri, 29 Mar 2002 14:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26296 for ; Fri, 29 Mar 2002 14:17:41 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29269 for ; Fri, 29 Mar 2002 14:17:37 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2TJH0I6028855; Fri, 29 Mar 2002 11:17:00 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01750; Fri, 29 Mar 2002 11:16:47 -0800 (PST) Message-ID: <3CA4BD95.AD53BD64@cisco.com> Date: Fri, 29 Mar 2002 14:16:37 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , "'sip@ietf.org'" , Dean Willis , Joerg Ott , "Rosen, Brian" , Rohan Mahy Subject: Re: FW: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A9@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > Some further notes below. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Friday, March 29, 2002 10:20 AM > > To: Peterson, Jon > > Cc: 'William Marshall'; 'sip@ietf.org' > > Subject: Re: FW: [Sip] Comment, SIP Privacy draft > > > [snip] > > > > > > I think it takes a relatively hostile reading of Call-Info to suggest > that > > > this is an appropriate usage. > > > > > > > No more hostile than to suggest that Remote-Party-Id is for user-asserted > > identity, when both the title, applicability statement and the text > throughout > > specifically says that the draft does not deal with user authentication. > The > > fact that Remote-Party-Id *can* be used for this is another story, just > like > > Call-Info *can* be used for this. > > > > One huge difference is that the backers of the Call-Info header did not > openly intend to use it for user-asserted identity (let alone any form of > identity). In the case of RPID this is exemplified in sip-privacy-04 by the > presence of the 'screen=' parameter. In the past, you've made the case that > carrying around unverified, user-asserted identities is useful for RPID. > This goes very much against the spirit of the AS. > No I have not. I have said (and still do), that if I receive a Remote-Party-Id from an untrusted source, then I should still be able to pass that along with the proper security settings (i.e. verified or not). Another source can be another network (for example a call originates from an Iraki service provider and enters a US network) which is my motivation. Now it just so happens that I can't (and won't) want to make a distiction between an untrusted user and an untrusted something else, because it doesn't make any sense to me. > I fear that we're losing sight of the points that motivated this whole > discussion (or more selfishly, my own involvement). I agree. > I don't want to destroy > sip-privacy-04. Well, I think it is an a coma, and is probably best left there for now. We are clearly getting nowhere on this issue, and there are other issues you have raised that we haven't even started addressing. One of the problems we are faced with is, that we do not have a common understanding of the problem we are trying to solve and the requirements that must be satisfied. At this point, I seriously doubt we are going to get to any kind of consensus without those, so I would suggest that our chairs identify someone to start driving problem statement and requirements for this (and it probably should not be any of us that have been involved too heavily in this discussion). Once we get those nailed down, we can then decide if the privacy-04 draft can be salvaged or if we need something completely new. Comments ? -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 14:50:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00858 for ; Fri, 29 Mar 2002 14:50:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28138 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 14:50:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26838; Fri, 29 Mar 2002 14:26:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26778 for ; Fri, 29 Mar 2002 14:26:06 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29665 for ; Fri, 29 Mar 2002 14:26:03 -0500 (EST) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2TJPS804314; Fri, 29 Mar 2002 14:25:28 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 13:25:22 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701AB@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:25:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Nearing the end now. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 11:03 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > > I really hope we all agree that the "proposal" Bill made to conflate RPID > > and Call-Info was not serious, but was intended to make a point about > > underspecification in the SIP spec, and also to illustrate that Call-Info > > has its own privacy implications. Right? > > > > No, we are actually quite serious. We have a problem that needs a solution, and > if the privacy draft ends up dying or otherwise does not provide that solution > very soon, we need an alternative. Since Call-Info is already spec'ed and we are > low on alternatives, the choice is pretty clear. > Well, fortunately, I am almost at a loss for words after this. Let me just say that I don't believe sip-privacy is dying - but nor do I believe we have all arrived at consensus about its usage. Switching gears to Call-Info or any other mechanism would only delay this process further, though, I feel. All of this talk about Call-Info, while it raises important concerns, has only drifted focus away from the issues that require immediate solutions. [snip] > > > > I can object, and I would. Why would anyone fail to object > to that usage? > > You cannot object to using an already defined header in specific ways, > regardless of whether it was intended to be used that way or not. > I disagree with this most strenuously. I believe it would require significant further standardization to make Call-Info something relevantly like RPID. Of course, you could choose to forgo the standards process in defining the needed capabilities - that is your prerogative. But provided that this is considered a standard SIP capability, I think the SIP community has the right to object to any such absurdities. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 15:47:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03131 for ; Fri, 29 Mar 2002 15:47:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00817 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 15:47:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29612; Fri, 29 Mar 2002 15:24:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29583 for ; Fri, 29 Mar 2002 15:24:40 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02217 for ; Fri, 29 Mar 2002 15:24:37 -0500 (EST) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2TKO0805453; Fri, 29 Mar 2002 15:24:01 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 14:23:55 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701AC@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , "'sip@ietf.org'" , Dean Willis , Joerg Ott , "Rosen, Brian" , Rohan Mahy Subject: RE: FW: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 14:23:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some final notes (for now). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 11:17 AM > To: Peterson, Jon > Cc: 'William Marshall'; 'sip@ietf.org'; Dean Willis; Joerg Ott; Rosen, > Brian; Rohan Mahy > Subject: Re: FW: [Sip] Comment, SIP Privacy draft > > > > In the past, you've made the case that > > carrying around unverified, user-asserted identities is useful for RPID. > > This goes very much against the spirit of the AS. > > > > No I have not. I have said (and still do), that if I receive a Remote-Party-Id > from an untrusted source, then I should still be able to pass that along with > the proper security settings (i.e. verified or not). Another source can be > another network (for example a call originates from an Iraki service provider > and enters a US network) which is my motivation. Now it just so happens that I > can't (and won't) want to make a distiction between an untrusted user and an > untrusted something else, because it doesn't make any sense to me. > Well, in the past IIRC you've made the case that you'd like to be informed when Mike Thomas pretends to be Elvis, but I suppose on reflection that I'd pay money to see that too. Seriously though, do we need an RPID to carry untrusted identity information? What's the difference between this and just carrying the untrusted identity in the From header, then? Are you saying then that we need multiple ways to carry untrusted information in SIP messages (one for user-asserted untrusted info, the From, and one for network-asserted untrusted info, the 'screen=no' RPID)? If an Iraqi network is not considered to be part of the 'trusted' PSTN, why do we need to preserve any identities that it has asserted (as opposed to identities that would appear in the From)? I agree that there probably isn't much difference between what an untrusted network and an untrusted user asserts - but I'm not sure why that argues for retaining the concept of an untrusted RPID, I think it actually argues for the opposite. A SIP message arriving from the Iraqi network will have a From header that we can safely treat as an untrusted identity - I'm not sure why we need more untrusted data. If the From field is anonymous, and an untrusted network-asserted identity is present in the RPID header, who would be the consumer of that untrusted RPID? The network couldn't rely on it for accounting or malicious call trace - it's untrusted. It shouldn't be displayed to end users - the originating user requested anonymity. So what's the use case for it, exactly? If there is none, then why carry it? There's got to be something here that I'm missing. [snip] > -- Flemming > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 16:06:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03580 for ; Fri, 29 Mar 2002 16:06:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01778 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 16:06:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00471; Fri, 29 Mar 2002 15:35:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00400 for ; Fri, 29 Mar 2002 15:35:24 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02690 for ; Fri, 29 Mar 2002 15:35:19 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2TKYbY22631; Fri, 29 Mar 2002 12:34:37 -0800 (PST) Received: from cisco.com (rtp-vpn1-23.cisco.com [10.82.224.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA29189; Fri, 29 Mar 2002 12:34:34 -0800 (PST) Message-ID: <3CA4CFD0.784BE935@cisco.com> Date: Fri, 29 Mar 2002 15:34:24 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , "'sip@ietf.org'" , Dean Willis , Joerg Ott , "Rosen, Brian" , Rohan Mahy Subject: Re: FW: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701AC@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > If an Iraqi network > is not considered to be part of the 'trusted' PSTN, why do we need to > preserve any identities that it has asserted (as opposed to identities that > would appear in the From)? I agree that there probably isn't much difference > between what an untrusted network and an untrusted user asserts - but I'm > not sure why that argues for retaining the concept of an untrusted RPID, I > think it actually argues for the opposite. A SIP message arriving from the > Iraqi network will have a From header that we can safely treat as an > untrusted identity - I'm not sure why we need more untrusted data. Let the user decide - don't make your policy an integral part of the protocol. > If the From field is anonymous, and an untrusted network-asserted identity > is present in the RPID header, who would be the consumer of that untrusted > RPID? The network couldn't rely on it for accounting or malicious call trace > - it's untrusted. It shouldn't be displayed to end users - the originating > user requested anonymity. So what's the use case for it, exactly? If there > is none, then why carry it? There's got to be something here that I'm > missing. > Indeed there is. Just because your network cannot verify the authenticity of the information does not mean the information is useless. With the present semantics, some people (I'm one of them) still find it useful from a pure caller-id service perspective to have a clear-text caller-id being presented although it was untrusted as opposed to having nothing at all, as long as I know it's untrusted. The longer term problem with your statement is that it assumes that the "screen" mechanism is the only authenticity mechanism forever. As I have stated many times, we expect a generic security solution that can authenticate various headers in the future. Once we get that, you can now have a Remote-Party-Id signed, sealed and delivered from an "untrusted" network and actually still be able to verify it even though your network provider can't vouch for it. Pretty useful - no ? -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 17:25:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05869 for ; Fri, 29 Mar 2002 17:25:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05868 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 17:25:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04760; Fri, 29 Mar 2002 17:00:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04713 for ; Fri, 29 Mar 2002 17:00:46 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05090 for ; Fri, 29 Mar 2002 17:00:40 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 91ADC1E138; Fri, 29 Mar 2002 16:59:47 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA15810; Fri, 29 Mar 2002 16:59:44 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id QAA64360; Fri, 29 Mar 2002 16:58:20 -0500 (EST) Date: Fri, 29 Mar 2002 16:58:20 -0500 (EST) Message-Id: <200203292158.QAA64360@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > I really hope we all agree that the "proposal" Bill made to conflate RPID > and Call-Info was not serious, but was intended to make a point about > underspecification in the SIP spec, and also to illustrate that Call-Info > has its own privacy implications. Right? Actually, the proposal is quite serious. PacketCable needs a solution for the CMSS spec, and waiting for IETF is not an option. We still have to deal with the missed deadline on the REFER draft too, somehow. While rfc2543 did not contain anything usable for this feature (and, therefore, we submitted draft-dcsgroup-sip-privacy 3 years ago), 2543bis does. A profile for this application is technically workable. > The real, material difference here is that people want to do Bad Things with > RPID, and RPID has broadened its definition and its mechanism to accomodate > these things in the name of privacy. Call-Info is merely underspecified. If anything, RPID is over-specified, and covers cases that (if every element was compliant) would never happen. That is much different from a statement that certain behavior MAY occur. I think that is the case with your whole list of "Bad Things", but can't say for sure because I've never seen such a list. And a lot of SIP is underspecified. That leads to new applications and new services, and is its advantage over other protocols that aren't and don't. We concluded long ago not to standardize services; lets keep it that way. > sip-privacy-04 says 'encrypt or remove', yes. But not enough information > about encyrption is provided for that to be a viable option - this isn't > entirely the privacy draft's fault, but sip-privacy-04 could have said more > than it does, anyway. It is also not clear to me how 'encryption' helps call > trace. Encryption would only be relevant to call trace in so far as all > entities that will be able to decrypt the RPIDs are trusted, ... Section 7.2 gives almost a full page of spec language on this subject, and a RECOMMENDED algorithm to do it. Listing the encrypting UA in the host port is the mechanism to get back to an entity that will be able to decrypt. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 12:33:26 -0600 A few notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 5:33 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > "Peterson, Jon" wrote: > [snip] > > OK - so we agree that Call-Info duplicates Remote-Party-Id functionality as far > as this point is concerned. All we need is someone specifying the usage. > I really hope we all agree that the "proposal" Bill made to conflate RPID and Call-Info was not serious, but was intended to make a point about underspecification in the SIP spec, and also to illustrate that Call-Info has its own privacy implications. Right? I think it would be problematic to suggest that the Call-Info and RPID should be conflated, as the remainder of my note bears out. [snip] > > > > > Should there be a mechanism in SIP that allows a user agent > to suggest that > > proxies treat their requests privately? Of course. I think > the presence of > > some sort of privacy flag/header in requests is a > reasonable way to do so > > (vide the RPID-Privacy header in sip-privacy today). > Guaranteeing privacy > > entails managing a number of headers that could potentially > divulge identity > > - Call-Info is one of many examples (the open-ended > User-Agent and Server > > headers could also be used as repositories for potentially > private data, let > > alone common headers like Via and Contact). > > Indeed they could, just like a Remote-Party-Id header can be used in ways people > did not intend to. But why is it, that this must be obstructed at all cost in > the privacy-draft case, but it's perfectly legit in the SIP spec ? In fact, if I > rewrote the privacy-draft to use Call-Info instead of Remote-Party-Id, what > would your arguments now be ? > To limit the scope of the Call-Info, since the Call-Info is not intended to be an network-verified identity carriage parameter. Of course. This is not 'legit' in the SIP spec. We all know that in the two-hundred-odd pages of the SIP spec there are many remaining nits and gotchas, even when one is not reading the text in bad faith. This is clearly a bad faith reading of 20.9. No one would honestly believe that Call-Info is intended as a network-verified identitiy carriage mechanism. If that were proposed, I believe the authors of bis09 would say that was not a correct usage. The real, material difference here is that people want to do Bad Things with RPID, and RPID has broadened its definition and its mechanism to accomodate these things in the name of privacy. Call-Info is merely underspecified. > > > > All that said, I feel that it is somewhat misleading to suggest that > > Call-Info and RPID actually have a similar function, or more directly, that > > Call-Info should in fact be replaced with RPID. > > Well, I would actually argue the other way. Let's drop Remote-Party-Id and just > use Call-Info since nobody can object to that. > I can object, and I would. Why would anyone fail to object to that usage? > > The note below actually > > suggests Call-Info could be used to implement a CLIP/CLIR service - suffice > > it to say I do not believe this was the intention behind 20.9 in bis09. > > Ahh, but it could be used in that way - why is there not an applicability > statement to make sure it can't be misused ? > Although I already said this above, it is worth reiterating that RPID purports to be a privacy mechanism, but it has been earmarked for use in a number of ways that reflect poorly on privacy. [snip differences between RPID and Call-Info] > > Well, why on earth are proxies allow to muck with it then ? Also, why does it > talk about "trust that element" ? This all sounds very familiar to me. > To your first question, I dunno, actually. I mean, I guess I could see cases where a service provider wanted to add their homepage HTTP URI to a request as it passed as a kind free advertising. Really, those are the only sorts of cases I can imagine. To you second question, if you get an email from someone that you don't know which contains an HTTP URL, should you follow that URL? No, it could lead you somewhere you don't want to go, or worse, download some malicious software. This is all that "trust that element" note is saying. People have really chosen to read that in a hostile way. [snip] > > > > Hmm, I quote: > > "Therefore, it is RECOMMENDED that a UA only render the information in the > Call-Info header field if it can verify the authenticity of the element that > originated the header field and trusts that element." > And your quotation here supports what position, exactly? The account I gave above of why you shouldn't follow arbitrary URLs was the motivation for this text, as far as I remember, and I read this as consistent with the above. > > > > Any resemblance between the two headers further breaks down when we begin to > > look at the functional behavior of RPID - when it is added, how screening > > operates, and so forth. The most important difference is that Call-Info > > entails no concept of trusted and untrusted networks which are most > > certainly entailed by the RPID header. The use of the RPID header is > > predicated on the configuration of a set of 'trusted' destinations which can > > inspect the RPID header, and the assumption that it must be removed if it is > > transferred to an untrusted entity. Personally, I don't think Call-Info > > requires any such concept if it is used as the spec seems to intend. > > > > A couple of problems here. First of all the Call-Info talks about trust without > specifying what that is. Secondly, you are talking about providing privacy for a > Call-Info header which you agreed above would be valuable, so the part about > "removing" before forwarding to untrusted entities ends up being the same (you > agreed above that a generic privacy mechanism should cover Call-Info). Finally, > Remote-Party-Id is not supposed to be removed when forwarded to an untrusted > entity - it is supposed to be encrypted so we can do call trace. > It's clear to me, anyway, that the 'trust' here is unrelated to the 'trusted network' concept in RPID. For one thing, the trust of Call-Info is a matter of human oversight. In much the same way that you choose to follow a URL in an email or not, you can choose to follow the URL in a Call-Info - this URL is intended to be consumed by humans. This is radically different than the identity in an RPID. Automatons (proxies) need to decide programmatically whether or not they "trust" the next hop to which they are sending signaling, and groom the RPIDs in messages appropriately. These two forms of trust are quite different. I see Call-Info as one of many ways that potentially private information could be communicated inadvertantly to an end user, so in that sense I agree it is valuable for the general SIP privacy mechanism to discuss Call-Info. However, I don't think Call-Info should play a role in expressing a network-verified identity of end-users. sip-privacy-04 says 'encrypt or remove', yes. But not enough information about encyrption is provided for that to be a viable option - this isn't entirely the privacy draft's fault, but sip-privacy-04 could have said more than it does, anyway. It is also not clear to me how 'encryption' helps call trace. Encryption would only be relevant to call trace in so far as all entities that will be able to decrypt the RPIDs are trusted, and that trusted elements encrypt the RPIDs so that they can pass through untrusted entities on the way to some other trusted entity. Encryption doesn't really make decisions about trust any easier (which key do I to encrypt RPIDs when I send them to an untrusted source? how do I know where the signaling will eventually end up?), it just pushes the problem around. > > > > > The argument that Call-Info is a subset of RPID I also find a little > > troublesome - when properly configured quite a few SIP headers, including at > > least To and From, could be represented by RPID. With the current > > extensibility mechanism in sip-privacy-04 I have no doubt it could be argued > > that RPID should replace all other means of asserting identity in SIP. > > Personally, I believe this is a defect of sip-privacy-04 rather than a > > strength. > > Yeah, nothing like the good old smokescreen. Nobody has suggested the above so > let's leave this out - shall we ? I am trying to argue in good faith here - this is not meant to be deceptive, but rather just to illustrate that if you want to conflate RPID with Call-Info, there are quite a few other headers you could also choose to lump in with those two. It is dangerous to go down that path, I think. > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 17:25:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05888 for ; Fri, 29 Mar 2002 17:25:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05900 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 17:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05007; Fri, 29 Mar 2002 17:01:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04978 for ; Fri, 29 Mar 2002 17:01:55 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05128 for ; Fri, 29 Mar 2002 17:01:50 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2TM1NZ25027; Fri, 29 Mar 2002 16:01:23 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 16:01:17 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701AF@va02.va.neustar.com> From: "Peterson, Jon" To: "'William Marshall'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 16:01:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A note below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, March 29, 2002 1:26 PM > To: jon.peterson@neustar.biz > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > [snip] > > Whether I'm the first to suggest use of Call-Info for this purpose > or not seems irrelevant. You state that it is to be used for displaying > optional content to the end-user, which is one of the main > problems being addressed in the privacy draft. In that sense, > it squarely meets the need. > Regardless of our differences of opinion about the requirements for a privacy mechanism in SIP, surely we all agree that the main problem of the privacy draft is not "displaying optional content to the end-user". The privacy draft defines an extension to SIP by which network elements can insert a verified identity into SIP messages in support of privacy, and prevent untrusted elements from inspecting this verified identity data. I think it's about NOT displaying certain content to the end-user, actually. I don't believe anyone, no matter how liberally they read bis09, could seriously contend that Call-Info provides such a mechanism. It would require significant further standardization to adapt Call-Info to these purposes. The sort of "optional content" Call-Info is intended to render, from the examples, is something like a web homepage. That much said, if you feel this is a credible proposal you are obviously empowered to write it up as a new practice for the evaluation of the working group, and it would no doubt be considered on its merits. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 17:25:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05905 for ; Fri, 29 Mar 2002 17:25:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA05889 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 17:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03916; Fri, 29 Mar 2002 16:56:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03811 for ; Fri, 29 Mar 2002 16:56:50 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04931 for ; Fri, 29 Mar 2002 16:56:41 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2TLu7Z24767; Fri, 29 Mar 2002 15:56:07 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 15:56:02 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701AE@va02.va.neustar.com> From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , "'sip@ietf.org'" , Dean Willis , Joerg Ott , "Rosen, Brian" , Rohan Mahy Subject: RE: FW: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 15:55:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org More, always more, below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 12:34 PM > To: Peterson, Jon > Cc: 'William Marshall'; 'sip@ietf.org'; Dean Willis; Joerg Ott; Rosen, > Brian; Rohan Mahy > Subject: Re: FW: [Sip] Comment, SIP Privacy draft > > > "Peterson, Jon" wrote: > [snip] > > Just because your network cannot verify the authenticity of the > information does not mean the information is useless. With the present > semantics, some people (I'm one of them) still find it useful from a pure > caller-id service perspective to have a clear-text caller-id being presented > although it was untrusted as opposed to having nothing at all, as long as I know > it's untrusted. This is the issue that I was trying to zoom in on. Who generates that caller-id that will be displayed to the UAS in your Iraqi case? The UAC? My point is that the From header already provides a clear-text caller-id that was generated by the originating user but not necessarily verified by any intermediary, right? With or without sip-privacy-04, the From header already provides an (untrusted) means for an end-user to assert an identity that could be displayed by the destination endpoint, which the destination endpoint does not know to be verified by the network. So what does untrusted RPID add to this? The only case I can think of where untrusted RPID potentially adds anything to the information about the caller are cases in which the originating user has requested privacy, and the From field therefore is Anonymous. But surely in this case the originating user has an expectation that their identity won't be revealed to the UAS - and so the motivation for carrying around unverified RPIDs can't be to display them to the UAS (i.e. caller-id) in this instance. So who is the consumer of the unverified RPID, then? I'm not questioning the motivation for casual, untrusted identities - I'm questioning why RPID has any bearing on this. This case is the subject of the concerns I raised in my last mail. I believe that the From field is sufficient to carry any identity of the client user that will be displayed by the UAS that has not necessarily been verified by the network. > The longer term problem with your statement is that it assumes > that the "screen" mechanism is the only authenticity mechanism forever. As I > have stated many times, we expect a generic security solution that can > authenticate various headers in the future. Once we get that, you can now have a > Remote-Party-Id signed, sealed and delivered from an "untrusted" network and > actually still be able to verify it even though your network provider can't > vouch for it. Pretty useful - no ? > Since I am (at the moment) only arguing for the removal of 'screen', I have a hard time seeing how I would have a problem with assuming that 'screen' goes away. Moreover I've argued that we can dispense with the 'screen' mechanism without solving the more difficult problem of signing RPIDs. The IOU above does not seem to encourage me to support the existing 'screen' mechanism, but rather to put everything on hold until we get to the more general mechanism. I'm not sure how this argues in favor of pushing the existing mechanism in sip-privacy-04 forward. What signing and encryption both really get you is a more flexible definition of the 'trusted' network. Today, in sip-privacy-04, a proxy server has to be pre-configured with a set of trusted hosts to which it can safely deliver and from which it can safely receive RPIDs - those are the trusted network. Signing and encryption remove this restriction, since each message can be evaluated on the basis of its signatures to determine whether or not a trusted source created the RPIDs regardless of whether or not a message was received directly from a trusted entity. However, in that instance a proxy that is trying to figure out whether or not it should trust a message must still be pre-configured with a set of trusted keys - it isn't that the 'trusted network' concept goes away, it is just no longer related to the next signaling hops, but rather to the encryption keys. This is a more powerful and flexible architecture, but many of the fundamental problems arising from the trusted network concept are not immediately resolved by the introduction of encryption and signing, it just shifts these problems around a little. I think ultimately signing messages might even be orthogonal to the issue of setting the 'screen=' parameter. How would encryption or signing help you with your Iraqi case? From what I read above I gather you'd still want to be able to carry unverified data, even if well-known encryption and signing practices were available? > -- Flemming > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 17:37:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06384 for ; Fri, 29 Mar 2002 17:37:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA06763 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 17:37:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05460; Fri, 29 Mar 2002 17:15:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05429 for ; Fri, 29 Mar 2002 17:15:55 -0500 (EST) Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05403 for ; Fri, 29 Mar 2002 17:15:50 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id ED1F11E08E; Fri, 29 Mar 2002 17:15:53 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA16061; Fri, 29 Mar 2002 17:15:50 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA54172; Fri, 29 Mar 2002 17:15:13 -0500 (EST) Date: Fri, 29 Mar 2002 17:15:13 -0500 (EST) Message-Id: <200203292215.RAA54172@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: FW: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > I don't want to destroy > sip-privacy-04. I want to see things like 'screen' removed so that the > mechanism comes into parity with the applicability. If you honestly > supported the sentiment you tout above, I believe you would have no problem > removing 'screen'. The issue here is whether the mechanism defined can be extended to other types of identity than calling-number and calling-name. Back long ago that was the only use; discussion on the list led to the consensus that additional types of identification should be allowed. So then what happens when one proxy doesn't understand a new identity type? Therefore the "screen" parameter. So is the argument to un-do last year's consensus? That part went a very long time with no comments. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , "'sip@ietf.org'" Subject: RE: FW: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:00:38 -0600 Some further notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 10:20 AM > To: Peterson, Jon > Cc: 'William Marshall'; 'sip@ietf.org' > Subject: Re: FW: [Sip] Comment, SIP Privacy draft > [snip] > > > > I think it takes a relatively hostile reading of Call-Info to suggest that > > this is an appropriate usage. > > > > No more hostile than to suggest that Remote-Party-Id is for user-asserted > identity, when both the title, applicability statement and the text throughout > specifically says that the draft does not deal with user authentication. The > fact that Remote-Party-Id *can* be used for this is another story, just like > Call-Info *can* be used for this. > One huge difference is that the backers of the Call-Info header did not openly intend to use it for user-asserted identity (let alone any form of identity). In the case of RPID this is exemplified in sip-privacy-04 by the presence of the 'screen=' parameter. In the past, you've made the case that carrying around unverified, user-asserted identities is useful for RPID. This goes very much against the spirit of the AS. I fear that we're losing sight of the points that motivated this whole discussion (or more selfishly, my own involvement). I don't want to destroy sip-privacy-04. I want to see things like 'screen' removed so that the mechanism comes into parity with the applicability. If you honestly supported the sentiment you tout above, I believe you would have no problem removing 'screen'. To me this is all about bringing the mechanism into conformity with the applicability. I only entered into this fray because of the ways that RPID was proposed to be used, because a concrete case was raised in which a major customer of SIP wanted to abuse RPID and create serious interoperability concerns. I don't think this is a double standard - the squeaky wheel gets the grease, and RPID happened to be squeaking. While you and Bill have made a reasonable case that Call-Info as its syntax is described could theoretically be misinterpreted, to date I must point out that it hasn't been (outside of this little thought-experiment). If someone did put out an I-D proposing the use of Call-Info for things along these lines (for example, proposing a 'screen=' and 'privacy=' parameter for Call-Info, and then appropriate proxy handling for Call-Info in a 'trusted federation of networks'), I doubt it would pass WGLC. Why these Call-Info arguments should encourage us to proceed with sip-privacy-04 as it stands is mysterious to me. > -- Flemming > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 17:51:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06774 for ; Fri, 29 Mar 2002 17:51:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA07184 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 17:51:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06597; Fri, 29 Mar 2002 17:32:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06563 for ; Fri, 29 Mar 2002 17:32:09 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06196 for ; Fri, 29 Mar 2002 17:32:03 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 973B64CFCD; Fri, 29 Mar 2002 17:32:07 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA16315; Fri, 29 Mar 2002 17:32:03 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA14318; Fri, 29 Mar 2002 17:31:47 -0500 (EST) Date: Fri, 29 Mar 2002 17:31:47 -0500 (EST) Message-Id: <200203292231.RAA14318@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > But anyway, in the quote above I was just making the less ambitious and more > specific point that 20.9 happens to state that the Call-Info characterizes > the entity that originated the message, and that this would seem to argue > against the inclusion of a rpi-pty-type parameter. Characterizing the entity that originated the message sounds like *exactly* what is needed. Subsriber, office-owner, calling-person, instrument, location - all this is characterizing the entity that originated the message. Even more general than what is needed. Call-Info allows a "card" type, so it can also include everything that rfc2426 does (birthday of the caller???). True, many other SIP parameters could be misinterpreted to contain identity information. Just like many are used to offload state information (as first described in draft-dcsgroup-sip-state). But since Call-Info has as its stated intent "optional content presentation to users", it is a far better fit, and hardly abusive. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:20:41 -0600 One more note here. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 10:31 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > [snip] > > > > > It also isn't correct that Call-Info contains all of the extensibility > > mechanisms of RPID. > > On the contrary - the production for info-param allows for unlimited > extensibility via generic-param. Why pick on Call-Info? Any number of SIP parameters could be misinterpreted to contain identity info, especially because they happen to be extensible. Via has a generic-param extension as well, so we could propose an 'rpid=' Via parameter that replicates RPID there, which each entity that generates a Via should add. The point is that the RPID header is intended to be part of some identity/privacy assertion mechanism - that's its reason for existing, and that is why it is has attracted these applicability concerns. Via and Call-Info have a different purpose, which is why (to date) we haven't had any reason to worry over their applicability - to date, no one has bothered to formally propose an abusive application of their extensibility. But anyway, in the quote above I was just making the less ambitious and more specific point that 20.9 happens to state that the Call-Info characterizes the entity that originated the message, and that this would seem to argue against the inclusion of a rpi-pty-type parameter. > > -- Flemming > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 18:15:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07146 for ; Fri, 29 Mar 2002 18:15:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08839 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 18:15:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07129; Fri, 29 Mar 2002 17:47:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07098 for ; Fri, 29 Mar 2002 17:47:07 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06709 for ; Fri, 29 Mar 2002 17:47:02 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id ECA094CF53; Fri, 29 Mar 2002 17:47:05 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA16449; Fri, 29 Mar 2002 17:47:02 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA57219; Fri, 29 Mar 2002 17:46:33 -0500 (EST) Date: Fri, 29 Mar 2002 17:46:33 -0500 (EST) Message-Id: <200203292246.RAA57219@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Let me just > say that I don't believe sip-privacy is dying - but nor do I believe we have > all arrived at consensus about its usage. Switching gears to Call-Info or > any other mechanism would only delay this process further, though, I feel. Glad to hear that, because it seems the opposite from here. The deadline given by ITU-SG9 was a frozen spec by the end of March, which is fast approaching. Since Call-Info is already defined in a published (or, frozen and soon to be published) specification, and is underspecified in that specification, there is no reason why a profile defining its usage needs to be delayed. It would certainly be nice to have a standardized solution to the problem. But not if that is three more years away (remember its been three years already). Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'Flemming Andreasen'" , "Peterson, Jon" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 13:25:16 -0600 Nearing the end now. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, March 29, 2002 11:03 AM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > > I really hope we all agree that the "proposal" Bill made to conflate RPID > > and Call-Info was not serious, but was intended to make a point about > > underspecification in the SIP spec, and also to illustrate that Call-Info > > has its own privacy implications. Right? > > > > No, we are actually quite serious. We have a problem that needs a solution, and > if the privacy draft ends up dying or otherwise does not provide that solution > very soon, we need an alternative. Since Call-Info is already spec'ed and we are > low on alternatives, the choice is pretty clear. > Well, fortunately, I am almost at a loss for words after this. Let me just say that I don't believe sip-privacy is dying - but nor do I believe we have all arrived at consensus about its usage. Switching gears to Call-Info or any other mechanism would only delay this process further, though, I feel. All of this talk about Call-Info, while it raises important concerns, has only drifted focus away from the issues that require immediate solutions. [snip] > > > > I can object, and I would. Why would anyone fail to object > to that usage? > > You cannot object to using an already defined header in specific ways, > regardless of whether it was intended to be used that way or not. > I disagree with this most strenuously. I believe it would require significant further standardization to make Call-Info something relevantly like RPID. Of course, you could choose to forgo the standards process in defining the needed capabilities - that is your prerogative. But provided that this is considered a standard SIP capability, I think the SIP community has the right to object to any such absurdities. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 19:51:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08595 for ; Fri, 29 Mar 2002 19:51:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13360 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 19:51:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12096; Fri, 29 Mar 2002 19:24:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12068 for ; Fri, 29 Mar 2002 19:24:49 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08234 for ; Fri, 29 Mar 2002 19:24:46 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA19118; Fri, 29 Mar 2002 19:24:36 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2U0OYPm008526 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Mar 2002 19:24:35 -0500 (EST) Message-ID: <3CA505A5.7B79B411@cs.columbia.edu> Date: Fri, 29 Mar 2002 19:24:05 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701A3@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > significantly limited in the process. For example, I'm not aware of the > motivation to allow proxies to add Call-Info, and on initial reflection that > doesn't seem indispensible. I have not exactly found the proponents of RPID > to be similarly accomodating. This can be very useful for my incoming proxy: You call me, my proxy looks up your web page or other similar information in a database, network information repository, etc. This is then presented to the (embedded) end system with your call. Usual caveats about trusting the information apply. Why should this functionality be ruled out? Short of disallowing users or proxies to insert any information in SDP (for users) or SIP headers, there is no way you can keep any proxy from inserting whatever they want. If this information is public, not much to object to. If my carrier or other party releases private information to a third party, including the request destination, without my consent this is presumably a breach of contract or a breach of law, depending on the jurisdiction. (In Europe, it would be an actionable offense.) We can help "good guys" do the right thing, by indicating our privacy desires. We can't keep bad guys from leaking information they have access to. Also, email has a long tradition of inserting information without explicit user consent, for example, X-Authentication-Warning. I think we should be careful of trying to over-engineer what's primarily a social or legal problem. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 19:52:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08631 for ; Fri, 29 Mar 2002 19:52:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13397 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 19:52:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12486; Fri, 29 Mar 2002 19:30:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12434 for ; Fri, 29 Mar 2002 19:30:29 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08305 for ; Fri, 29 Mar 2002 19:30:26 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2U0TwZ29507; Fri, 29 Mar 2002 18:29:58 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 18:29:53 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701B0@va02.va.neustar.com> From: "Peterson, Jon" To: "'William Marshall'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 18:29:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Batching up some of Bill's mails below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, March 29, 2002 1:58 PM > To: jon.peterson@neustar.biz > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > [snip] > > If anything, RPID is over-specified, and covers cases that (if every > element was compliant) would never happen. That is much different from > a statement that certain behavior MAY occur. I think that is the case > with your whole list of "Bad Things", but can't say for sure because I've > never seen such a list. > Specifically, I am concerned with RPID usage as a replacement for the To and From headers, in architectures which have proposed that To and From should always contain random/anonymous information for all calls (not just when privacy is needed) and RPID alone should be used to assert originating and destination identities. I feel that these architectures pose tangible threats to interoperability. Moreover, I feel there are capabilities in sip-privacy-04 that support this architecture which have no apparent internal motivation and which are not integral to the privacy function that sip-privacy-04 attempts to provide. Were the SIP WG to pass sip-privacy-04 as it stands it would be unnecessarily open to these sorts of abuses (though I would be the first to note that it is better than -03, which had no applicability statement and did not require IANA registration for extensions). If the remaining loopholes were closed, I would go back to ignoring sip-privacy-* as I have in the past; it certainly was not until I heard about the RPID To/From replacement architectures that I became, as I am now, interested is seeing changes to the draft. If you would like to see the changes I suggested, they are available in the ML archives here: http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html This is not to say that all SIP headers must be overspecified to prevent such abuses. Again, this happened to come up for RPID and not for anything else, and the squeaky wheel gets the grease. That much said, I think Call-Info has not invited this particular abuse in the past because it would need to have many concepts added to it ('screen=', 'privacy=', proxy handling rules) before it became anything like the RPID. [snip] > > Section 7.2 gives almost a full page of spec language on this subject, and > a RECOMMENDED algorithm to do it. Listing the encrypting UA in the host > port is the mechanism to get back to an entity that will be > able to decrypt. There's a RECOMMENDED algorithm? I just went through the document looking for one and I couldn't find it. All I see is something about symmetric keys and Base64 encoding. Where does it name something like DES, or AES, or what have you for encryption? There are also some issues with the mechanism in so far as a trusted entity sends out a chunk of encrypted data in an RPID that only it can decrypt, and then expects entities that want access to this information to 'get back' to them via the given hostname and port. First of all, while it may be specified elsewhere, nothing that I can see in sip-privacy-04 tells me how I can 'get back' to the host that generated the encrypted data. What should I expect is listening on that hostname or port? A SIP server? If so, what sort of request do I send to it (suggesting "please decrypt this string", maybe)? Have any NAT or firewall considerations been taken into account for this? How does the server decide whether or not it should grant you access to the plaintext string? There are a number of issues along these lines... The only alternative to 'getting back' to the host that generated the string doesn't sound like a very well-defined prospect: However, there is also no well-defined way for a downstream (trusted) entity to determine the identity of the calling party, without that entity knowing both the details of how the private "addr-spec" was constructed (crypto algorithm, MAC, encoding, etc.) as well as which key to use for decrypting the information. The solutions to these problems are left as an exercise to the reader, and hence interoperability should not be expected. So I think I will stand by my statement that not enough information about encryption is provided for this to be a viable option. Again, it may be specified elsewhere, but it doesn't seem to be in sip-privacy-04. ---- Next mail > > But anyway, in the quote above I was just making the less ambitious and more > > specific point that 20.9 happens to state that the Call-Info characterizes > > the entity that originated the message, and that this would seem to argue > > against the inclusion of a rpi-pty-type parameter. > > Characterizing the entity that originated the message sounds like *exactly* > what is needed. Subsriber, office-owner, calling-person, instrument, > location - all this is characterizing the entity that originated the > message. Even more general than what is needed. Call-Info allows > a "card" type, so it can also include everything that rfc2426 does > (birthday of the caller???). Um, sorry to be imprecise, by 'characterizes the entity that originated the message' I meant that Call-Info assumes that the originator of the message is the entity described in the Call-Info - so it assumes a single value, effectively, for what the rpi-pty-type would specify for the RPID (whether the RPID characterizes the 'caller' or 'callee' or what have you). I wasn't trying to make a broader statement about Call-Info's vocation. > > True, many other SIP parameters could be misinterpreted to contain > identity information. Just like many are used to offload state > information (as first described in draft-dcsgroup-sip-state). > But since Call-Info has as its stated intent "optional content > presentation to users", it is a far better fit, and hardly abusive. It's not 'optional content presentation', it's 'display optional content'. The difference between the two is that the RPID means "it is important whether or not this information should be displayed to the end user - only do so when the end user is trusted" whereas the Call-Info means "this is unimportant information that the end user should display if they can, otherwise, don't worry about it." > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Peterson, Jon" > To: "'Flemming Andreasen'" , > "Peterson, Jon" > Cc: "'William Marshall'" , sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > Date: Fri, 29 Mar 2002 12:33:26 -0600 > > A few notes below. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Friday, March 29, 2002 5:33 AM > > To: Peterson, Jon > > Cc: 'William Marshall'; sip@ietf.org > > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > > > > > > "Peterson, Jon" wrote: > > > [snip] > > > > OK - so we agree that Call-Info duplicates Remote-Party-Id > functionality > as far > > as this point is concerned. All we need is someone > specifying the usage. > > > > I really hope we all agree that the "proposal" Bill made to > conflate RPID > and Call-Info was not serious, but was intended to make a point about > underspecification in the SIP spec, and also to illustrate > that Call-Info > has its own privacy implications. Right? > > I think it would be problematic to suggest that the Call-Info and RPID > should be conflated, as the remainder of my note bears out. > > [snip] > > > > > > > > Should there be a mechanism in SIP that allows a user agent > > to suggest that > > > proxies treat their requests privately? Of course. I think > > the presence of > > > some sort of privacy flag/header in requests is a > > reasonable way to do so > > > (vide the RPID-Privacy header in sip-privacy today). > > Guaranteeing privacy > > > entails managing a number of headers that could potentially > > divulge identity > > > - Call-Info is one of many examples (the open-ended > > User-Agent and Server > > > headers could also be used as repositories for potentially > > private data, let > > > alone common headers like Via and Contact). > > > > Indeed they could, just like a Remote-Party-Id header can > be used in ways > people > > did not intend to. But why is it, that this must be > obstructed at all cost > in > > the privacy-draft case, but it's perfectly legit in the SIP > spec ? In > fact, if I > > rewrote the privacy-draft to use Call-Info instead of > Remote-Party-Id, > what > > would your arguments now be ? > > > > To limit the scope of the Call-Info, since the Call-Info is > not intended to > be an network-verified identity carriage parameter. Of course. > > This is not 'legit' in the SIP spec. We all know that in the > two-hundred-odd > pages of the SIP spec there are many remaining nits and > gotchas, even when > one is not reading the text in bad faith. This is clearly a bad faith > reading of 20.9. No one would honestly believe that Call-Info > is intended as > a network-verified identitiy carriage mechanism. If that were > proposed, I > believe the authors of bis09 would say that was not a correct usage. > > The real, material difference here is that people want to do > Bad Things with > RPID, and RPID has broadened its definition and its mechanism > to accomodate > these things in the name of privacy. Call-Info is merely > underspecified. > > > > > > > > All that said, I feel that it is somewhat misleading to > suggest that > > > Call-Info and RPID actually have a similar function, or > more directly, > that > > > Call-Info should in fact be replaced with RPID. > > > > Well, I would actually argue the other way. Let's drop > Remote-Party-Id and > just > > use Call-Info since nobody can object to that. > > > > I can object, and I would. Why would anyone fail to object to > that usage? > > > > The note below actually > > > suggests Call-Info could be used to implement a CLIP/CLIR > service - > suffice > > > it to say I do not believe this was the intention behind > 20.9 in bis09. > > > > Ahh, but it could be used in that way - why is there not an > applicability > > statement to make sure it can't be misused ? > > > > Although I already said this above, it is worth reiterating that RPID > purports to be a privacy mechanism, but it has been earmarked > for use in a > number of ways that reflect poorly on privacy. > > [snip differences between RPID and Call-Info] > > > > Well, why on earth are proxies allow to muck with it then ? > Also, why does > it > > talk about "trust that element" ? This all sounds very > familiar to me. > > > > To your first question, I dunno, actually. I mean, I guess I > could see cases > where a service provider wanted to add their homepage HTTP > URI to a request > as it passed as a kind free advertising. Really, those are > the only sorts of > cases I can imagine. > > To you second question, if you get an email from someone that > you don't know > which contains an HTTP URL, should you follow that URL? No, > it could lead > you somewhere you don't want to go, or worse, download some malicious > software. This is all that "trust that element" note is > saying. People have > really chosen to read that in a hostile way. > > [snip] > > > > > > > Hmm, I quote: > > > > "Therefore, it is RECOMMENDED that a UA only render the > information in > the > > Call-Info header field if it can verify the authenticity of > the element > that > > originated the header field and trusts that element." > > > > And your quotation here supports what position, exactly? The > account I gave > above of why you shouldn't follow arbitrary URLs was the > motivation for this > text, as far as I remember, and I read this as consistent > with the above. > > > > > > > > Any resemblance between the two headers further breaks > down when we > begin to > > > look at the functional behavior of RPID - when it is added, how > screening > > > operates, and so forth. The most important difference is > that Call-Info > > > entails no concept of trusted and untrusted networks > which are most > > > certainly entailed by the RPID header. The use of the > RPID header is > > > predicated on the configuration of a set of 'trusted' > destinations which > can > > > inspect the RPID header, and the assumption that it must > be removed if > it is > > > transferred to an untrusted entity. Personally, I don't > think Call-Info > > > requires any such concept if it is used as the spec seems > to intend. > > > > > > > A couple of problems here. First of all the Call-Info talks > about trust > without > > specifying what that is. Secondly, you are talking about > providing privacy > for a > > Call-Info header which you agreed above would be valuable, > so the part > about > > "removing" before forwarding to untrusted entities ends up > being the same > (you > > agreed above that a generic privacy mechanism should cover > Call-Info). > Finally, > > Remote-Party-Id is not supposed to be removed when forwarded to an > untrusted > > entity - it is supposed to be encrypted so we can do call trace. > > > > It's clear to me, anyway, that the 'trust' here is unrelated > to the 'trusted > network' concept in RPID. For one thing, the trust of > Call-Info is a matter > of human oversight. In much the same way that you choose to > follow a URL in > an email or not, you can choose to follow the URL in a > Call-Info - this URL > is intended to be consumed by humans. This is radically > different than the > identity in an RPID. Automatons (proxies) need to decide > programmatically > whether or not they "trust" the next hop to which they are sending > signaling, and groom the RPIDs in messages appropriately. > These two forms of > trust are quite different. > > I see Call-Info as one of many ways that potentially private > information > could be communicated inadvertantly to an end user, so in > that sense I agree > it is valuable for the general SIP privacy mechanism to > discuss Call-Info. > However, I don't think Call-Info should play a role in expressing a > network-verified identity of end-users. > > sip-privacy-04 says 'encrypt or remove', yes. But not enough > information > about encyrption is provided for that to be a viable option - > this isn't > entirely the privacy draft's fault, but sip-privacy-04 could > have said more > than it does, anyway. It is also not clear to me how > 'encryption' helps call > trace. Encryption would only be relevant to call trace in so > far as all > entities that will be able to decrypt the RPIDs are trusted, and that > trusted elements encrypt the RPIDs so that they can pass > through untrusted > entities on the way to some other trusted entity. Encryption > doesn't really > make decisions about trust any easier (which key do I to > encrypt RPIDs when > I send them to an untrusted source? how do I know where the > signaling will > eventually end up?), it just pushes the problem around. > > > > > > > > > The argument that Call-Info is a subset of RPID I also > find a little > > > troublesome - when properly configured quite a few SIP headers, > including at > > > least To and From, could be represented by RPID. With the current > > > extensibility mechanism in sip-privacy-04 I have no doubt > it could be > argued > > > that RPID should replace all other means of asserting > identity in SIP. > > > Personally, I believe this is a defect of sip-privacy-04 > rather than a > > > strength. > > > > Yeah, nothing like the good old smokescreen. Nobody has > suggested the > above so > > let's leave this out - shall we ? > > I am trying to argue in good faith here - this is not meant > to be deceptive, > but rather just to illustrate that if you want to conflate RPID with > Call-Info, there are quite a few other headers you could also > choose to lump > in with those two. It is dangerous to go down that path, I think. > > > > > -- Flemming > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 19:52:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08647 for ; Fri, 29 Mar 2002 19:52:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13414 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 19:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12833; Fri, 29 Mar 2002 19:34:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12802 for ; Fri, 29 Mar 2002 19:34:48 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08364 for ; Fri, 29 Mar 2002 19:34:45 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA20217; Fri, 29 Mar 2002 19:34:47 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2U0YkPm008838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Mar 2002 19:34:47 -0500 (EST) Message-ID: <3CA50808.F4C24132@cs.columbia.edu> Date: Fri, 29 Mar 2002 19:34:16 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] Privacy or Caller-ID? References: <000101c1d740$cd1d8ff0$bb036e3f@TXDWILLIS2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Except that it breaks SIP syntax rules, possibly yes. Dean Willis wrote: > > Please take a look at > > http://search.ietf.org/internet-drafts/draft-ema-vpim-clid-03.txt > > This draft defines Caller-ID and Caller-Name headers that could be > readily mapped into SIP. > > I suspect all it needs is a Caller-ID-Restriction header to be able to > provide CLID-CLIR interowrking between PSTN and a closed SIP network. > > Comments? > > -- > Dean > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 19:59:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08766 for ; Fri, 29 Mar 2002 19:59:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13660 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 19:59:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12964; Fri, 29 Mar 2002 19:41:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12933 for ; Fri, 29 Mar 2002 19:41:11 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08436 for ; Fri, 29 Mar 2002 19:41:09 -0500 (EST) Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g2U0e9811471; Fri, 29 Mar 2002 19:40:09 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 18:40:04 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701B1@va02.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 18:39:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A few comments below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 29, 2002 4:24 PM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > significantly limited in the process. For example, I'm not aware of the > > motivation to allow proxies to add Call-Info, and on initial reflection that > > doesn't seem indispensible. I have not exactly found the proponents of RPID > > to be similarly accomodating. > > This can be very useful for my incoming proxy: You call me, my proxy > looks up your web page or other similar information in a database, > network information repository, etc. This is then presented to the > (embedded) end system with your call. Usual caveats about trusting the > information apply. Why should this functionality be ruled out? > Well, at the very least it has some privacy concerns, as you suggest below. The proposal on the table is apparently to overload Call-Info to allow proxies to share your identity amongst themselves as an alternative to standardizing the RPID header. I think overloading the Call-Info header for this purpose should be discouraged; I don't have any strong intuition about the best way to discourage it. > Short of disallowing users or proxies to insert any information in SDP > (for users) or SIP headers, there is no way you can keep any proxy from > inserting whatever they want. If this information is public, not much to > object to. If my carrier or other party releases private information to > a third party, including the request destination, without my consent > this is presumably a breach of contract or a breach of law, depending on > the jurisdiction. (In Europe, it would be an actionable offense.) We can > help "good guys" do the right thing, by indicating our privacy desires. > We can't keep bad guys from leaking information they have access to. > Agreed that all we can do here in the SIP WG is not standardize bad designs. Definitely agreed that the mechanism by which a user expresses privacy preferences should apply to headers like the Call-Info, and that we have to acknowledge that service providers acting in bad faith can and will disregard these preferences. > Also, email has a long tradition of inserting information without > explicit user consent, for example, X-Authentication-Warning. > > I think we should be careful of trying to over-engineer what's primarily > a social or legal problem. I'll grant that over-engineering here is a risk. I'm just saying that we shouldn't push the problem of network-verified identity into the Call-Info header; this would not create any additional leverage on the problem (other than the perception, apparently, that this can be finalized without the consent of the SIP WG). > > Henning > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 21:21:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09687 for ; Fri, 29 Mar 2002 21:21:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17746 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 21:21:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15903; Fri, 29 Mar 2002 20:36:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15838 for ; Fri, 29 Mar 2002 20:36:24 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09205 for ; Fri, 29 Mar 2002 20:36:16 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA26515; Fri, 29 Mar 2002 20:36:13 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2U1aCPm010546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Mar 2002 20:36:12 -0500 (EST) Message-ID: <3CA5166E.6B4FBECF@cs.columbia.edu> Date: Fri, 29 Mar 2002 20:35:42 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'William Marshall'" , sip@ietf.org Subject: Re: [Sip] Comment, SIP Privacy draft References: <70565611B164D511957A001083FCDD56018701B1@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Well, at the very least it has some privacy concerns, as you suggest below. I don't think we disagree, but just to clarify: There are no privacy concerns if a proxy under my control inserts information it has access to, as long as this proxy is not doing a black-bag job getting this information. If you call me, I have every right to find out whatever is legal to find out about you and have my proxy insert this information in any way it sees fit. I don't think it helps the precision of the argument if we conflate everything into "privacy". The privacy concern is that if a third party, neither caller nor callee, has access to privileged information and inserts this without the consent of the owner of the information. As to what information is allowed to be inserted or not is a matter of law, contract and custom, not technology. As a trivial example, for an 800#-call, the calling number will be inserted and made visible to the callee regardless of whether the caller likes that feature or not. The caller's only choice is not to make the call or pay with his own dime. > The proposal on the table is apparently to overload Call-Info to allow > proxies to share your identity amongst themselves as an alternative to > standardizing the RPID header. I think overloading the Call-Info header for > this purpose should be discouraged; I don't have any strong intuition about > the best way to discourage it. I agree that overloading is harmful, particularly if the trust and control semantics are different. Call-Info and Alert-Info have no in-band trust indication or notion as to who can and should insert or remove it. I find this distinction more important than the difference between a name and a URL. > Agreed that all we can do here in the SIP WG is not standardize bad designs. > Definitely agreed that the mechanism by which a user expresses privacy > preferences should apply to headers like the Call-Info, and that we have to > acknowledge that service providers acting in bad faith can and will > disregard these preferences. If Call-Info (and maybe other headers) are inserted by the caller, the issue is "can you trust the information?". If it's inserted by a proxy, the issue is also "is the proxy allowed to do that, legally speaking?". In general, I could see a need for, say, a caller-preferences indication that would say "don't route my call where my identity is likely to be revealed". Indeed, caller-preferences may well have suitable mechanism (preference vs. don't-make-the-call-if-you-can't-oblige) already in place, only needing the appropriate labels. The practical problem with any such policy is that it is, well, policy. I'd be worried about granularity and expressiveness ("Call-Info is ok, but only if the call isn't routed to a foreign country with nasty local intelligence services"). > > > Also, email has a long tradition of inserting information without > > explicit user consent, for example, X-Authentication-Warning. > > > > I think we should be careful of trying to over-engineer what's primarily > > a social or legal problem. > > I'll grant that over-engineering here is a risk. I'm just saying that we > shouldn't push the problem of network-verified identity into the Call-Info > header; this would not create any additional leverage on the problem (other > than the perception, apparently, that this can be finalized without the > consent of the SIP WG). While I'm not disagreeing with your specific sentiment, I can sympathize with the frustration of the authors of the "privacy" draft. I would feel better if we could get away from intent and such, and focus on who inserts what information where, making sure that the recipient of the information has enough data to judge the trustworthiness (or knows that this is always untrustworthy). As long as information doesn't make false pretenses and misleads implementors and users, intent is just a bit too much beyond engineering. I think attempts to align any differences between promises and reality in the draft, as already happening with wording suggestions regarding "privacy", are more helpful. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 21:42:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11055 for ; Fri, 29 Mar 2002 21:42:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA18694 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 21:42:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17619; Fri, 29 Mar 2002 21:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17588 for ; Fri, 29 Mar 2002 21:14:34 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09627 for ; Fri, 29 Mar 2002 21:14:31 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2U2DMU15587; Fri, 29 Mar 2002 20:13:22 -0600 From: "Dean Willis" To: "'Henning Schulzrinne'" , "'Dean Willis'" Cc: Subject: RE: [Sip] Privacy or Caller-ID? Date: Fri, 29 Mar 2002 20:12:45 -0600 Message-ID: <002201c1d790$624eabf0$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3CA50808.F4C24132@cs.columbia.edu> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Notice I said "readily mapped", not "cut and pasted" . . . -- Dean > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Friday, March 29, 2002 6:34 PM > To: Dean Willis > Cc: sip@ietf.org > Subject: Re: [Sip] Privacy or Caller-ID? > > > Except that it breaks SIP syntax rules, possibly yes. > > Dean Willis wrote: > > > > Please take a look at > > > > http://search.ietf.org/internet-drafts/draft-ema-vpim-clid-03.txt > > > > This draft defines Caller-ID and Caller-Name headers that could be > > readily mapped into SIP. > > > > I suspect all it needs is a Caller-ID-Restriction header to > be able to > > provide CLID-CLIR interowrking between PSTN and a closed > SIP network. > > > > Comments? > > > > -- > > Dean > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on > current sip Use > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Mar 29 22:47:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13011 for ; Fri, 29 Mar 2002 22:47:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA21605 for sip-archive@odin.ietf.org; Fri, 29 Mar 2002 22:47:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19641; Fri, 29 Mar 2002 22:04:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19611 for ; Fri, 29 Mar 2002 22:04:37 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11353 for ; Fri, 29 Mar 2002 22:04:33 -0500 (EST) Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2U346U15853 for ; Fri, 29 Mar 2002 21:04:06 -0600 From: "Dean Willis" To: Date: Fri, 29 Mar 2002 21:03:30 -0600 Message-ID: <004001c1d797$78aece00$bb036e3f@TXDWILLIS2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Privacy draft and Call trace requirements. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here's the "other" usage of Privacy mechanisms as I understand it. There exists a requirement that messages forwarded outside of a domain of trust may be "traced" back to their original sender with the explicit cooperation of the domain of trust. I can't say where this requirement is documented, but it's certainly floating around there somewhere. So let's say I'm on L3's network, and I place a call. L3 inserts an RPID saying "dwillis@level3.com" This call is delivered to my Badcom 3GPP mobile, and we assume that we don't have explicit trust between L3 and Badcom (hey, they MIGHT actually have it, I don't know.) So L3's proxy encrypts the RPID using a key known to the L3 domain and kicks it on over to Badcom. The fugitive executive who ran off with my pension fund that I'm harassing (right) calls Badcom and complains. They pull their logs, find the INVITE, and call their buds at L3 and request a check. Ahah, says L3, that's Dean, he's a known troublemaker . . . So far so good. But please check my logic, I think I'm getting nervous. Assume the evil executive wants revenge . . . And remember, we don't really trust Badcom. So somebody in his employee makes a new call, replaying the L3-encrypted RPID header from my call, and sends it to Col. BadAttitude in a nearby third-world datahaven, along with a really unpleasant message payload. So BadAttitude sends out the hit squad, they get my name from L3, and Pow! -- no more working group chair. In other words, where's the replay protection? It's not in the "trust", because we've explicity described the trace requirements as ACROSS trust boundaries. Then again, maybe I just need to head out for supper -- it IS 2100 on Friday night, after all . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 00:44:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16560 for ; Sat, 30 Mar 2002 00:44:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25794 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 00:44:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23724; Fri, 29 Mar 2002 23:51:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23691 for ; Fri, 29 Mar 2002 23:51:02 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13953 for ; Fri, 29 Mar 2002 23:50:57 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 2ECD24CE14; Fri, 29 Mar 2002 23:50:58 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA19763; Fri, 29 Mar 2002 23:50:54 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id XAA89630; Fri, 29 Mar 2002 23:50:30 -0500 (EST) Date: Fri, 29 Mar 2002 23:50:30 -0500 (EST) Message-Id: <200203300450.XAA89630@fish.research.att.com> To: dwillis@dynamicsoft.com Cc: sip@ietf.org Subject: Re: [Sip] Privacy draft and Call trace requirements. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dean Willis wrote: Replay protection is not a necessary part of the story. The employee of the fugitive executive simply reads the RPID header to Col BadAttitude, or includes it in the text of a email message, or whatever. The problem is that L3 gave away your identity information outside the trust boundary. (At least I don't think you were saying that Col BadAttitude worked for L3). If L3 was going to do that then there is no point in encrypting the RPID header in the first place - if anyone walking in off the street with an encrypted header gets it decrypted free, not even a "make by bottom line positive this quarter" fee. If you've ever had experience with harassing phone calls (as I have recently), dialing *57 does not tell you the caller, it tells the police the identity of the caller. You never find out. In some sense, that is keeping the information within their trust boundary. As Henning pointed out, giving this information out is, in some countries, actionable. Bill Marshall wtm@research.att.com -----original story----- From: "Dean Willis" To: Date: Fri, 29 Mar 2002 21:03:30 -0600 Subject: [Sip] Privacy draft and Call trace requirements. Here's the "other" usage of Privacy mechanisms as I understand it. There exists a requirement that messages forwarded outside of a domain of trust may be "traced" back to their original sender with the explicit cooperation of the domain of trust. I can't say where this requirement is documented, but it's certainly floating around there somewhere. So let's say I'm on L3's network, and I place a call. L3 inserts an RPID saying "dwillis@level3.com" This call is delivered to my Badcom 3GPP mobile, and we assume that we don't have explicit trust between L3 and Badcom (hey, they MIGHT actually have it, I don't know.) So L3's proxy encrypts the RPID using a key known to the L3 domain and kicks it on over to Badcom. The fugitive executive who ran off with my pension fund that I'm harassing (right) calls Badcom and complains. They pull their logs, find the INVITE, and call their buds at L3 and request a check. Ahah, says L3, that's Dean, he's a known troublemaker . . . So far so good. But please check my logic, I think I'm getting nervous. Assume the evil executive wants revenge . . . And remember, we don't really trust Badcom. So somebody in his employee makes a new call, replaying the L3-encrypted RPID header from my call, and sends it to Col. BadAttitude in a nearby third-world datahaven, along with a really unpleasant message payload. So BadAttitude sends out the hit squad, they get my name from L3, and Pow! -- no more working group chair. In other words, where's the replay protection? It's not in the "trust", because we've explicity described the trace requirements as ACROSS trust boundaries. Then again, maybe I just need to head out for supper -- it IS 2100 on Friday night, after all . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 00:48:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16592 for ; Sat, 30 Mar 2002 00:48:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25900 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 00:48:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25061; Sat, 30 Mar 2002 00:26:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24941 for ; Sat, 30 Mar 2002 00:26:13 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16171 for ; Sat, 30 Mar 2002 00:26:10 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 31AF34CE14; Sat, 30 Mar 2002 00:26:12 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA19984; Sat, 30 Mar 2002 00:26:08 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id AAA21200; Sat, 30 Mar 2002 00:22:51 -0500 (EST) Date: Sat, 30 Mar 2002 00:22:51 -0500 (EST) Message-Id: <200203300522.AAA21200@fish.research.att.com> To: jon.peterson@neustar.biz Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Specifically, I am concerned with RPID usage as a replacement for the To and > From headers, in architectures which have proposed that To and From should > always contain random/anonymous information for all calls (not just when > privacy is needed) and RPID alone should be used to assert originating and > destination identities. privacy-04 already says that UA's don't insert RPID headers. If a UA is going to do it anyway, I don't see how a MUST NOT will stop it. At the proxy, it still needs to handle INVITEs from both trusted and untrusted sources, so considering the UA an untrusted source simplifies the number of cases to specify and handles some errors. I'd tend to agree that such architectures may cause interoperability problems, but have no basis in facts for that belief. > If you would like to see > the changes I suggested, they are available in the ML archives here: > > http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html Flemming already responded to this message, point by point, msg04277.html. > There are also some issues with the mechanism in so far as a trusted entity > sends out a chunk of encrypted data in an RPID that only it can decrypt, and > then expects entities that want access to this information to 'get back' to > them via the given hostname and port. First of all, while it may be > specified elsewhere, nothing that I can see in sip-privacy-04 tells me how I > can 'get back' to the host that generated the encrypted data. Section 7.2 clearly states that it generates a sip: or sips: URI, and has requirements for the content of the hostport, and for the contents of the username, and for a user-param. Section 6.1 states that such a URI can be used as a Request-URI by the UA for certain call control functions or subsequent calls. While the mechanisms you described can also be done, a simple INVITE to the enrypted URI is simpler. > Um, sorry to be imprecise, by 'characterizes the entity that originated the > message' I meant that Call-Info assumes that the originator of the message > is the entity described in the Call-Info - so it assumes a single value, > effectively, for what the rpi-pty-type would specify for the RPID (whether > the RPID characterizes the 'caller' or 'callee' or what have you). I wasn't > trying to make a broader statement about Call-Info's vocation. I had confused rpi-pty-type and rpi-id-type. Your point. > > But since Call-Info has as its stated intent "optional content > > presentation to users", it is a far better fit, and hardly abusive. > > It's not 'optional content presentation', it's 'display optional content'. bis-09 Section 28.2, first bullet item. Its "optional content presentation to users" > .... whereas the Call-Info means "this is > unimportant information that the end user should display if they can, > otherwise, don't worry about it." My old rotary phone does exactly this with the Caller-ID info. Perhaps I need to upgrade my UA. Bill Marshall wtm@research.att.com -----original message----- From: "Peterson, Jon" To: "'William Marshall'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Fri, 29 Mar 2002 18:29:47 -0600 Batching up some of Bill's mails below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, March 29, 2002 1:58 PM > To: jon.peterson@neustar.biz > Cc: sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > [snip] > > If anything, RPID is over-specified, and covers cases that (if every > element was compliant) would never happen. That is much different from > a statement that certain behavior MAY occur. I think that is the case > with your whole list of "Bad Things", but can't say for sure because I've > never seen such a list. > Specifically, I am concerned with RPID usage as a replacement for the To and >From headers, in architectures which have proposed that To and From should always contain random/anonymous information for all calls (not just when privacy is needed) and RPID alone should be used to assert originating and destination identities. I feel that these architectures pose tangible threats to interoperability. Moreover, I feel there are capabilities in sip-privacy-04 that support this architecture which have no apparent internal motivation and which are not integral to the privacy function that sip-privacy-04 attempts to provide. Were the SIP WG to pass sip-privacy-04 as it stands it would be unnecessarily open to these sorts of abuses (though I would be the first to note that it is better than -03, which had no applicability statement and did not require IANA registration for extensions). If the remaining loopholes were closed, I would go back to ignoring sip-privacy-* as I have in the past; it certainly was not until I heard about the RPID To/From replacement architectures that I became, as I am now, interested is seeing changes to the draft. If you would like to see the changes I suggested, they are available in the ML archives here: http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html This is not to say that all SIP headers must be overspecified to prevent such abuses. Again, this happened to come up for RPID and not for anything else, and the squeaky wheel gets the grease. That much said, I think Call-Info has not invited this particular abuse in the past because it would need to have many concepts added to it ('screen=', 'privacy=', proxy handling rules) before it became anything like the RPID. [snip] > > Section 7.2 gives almost a full page of spec language on this subject, and > a RECOMMENDED algorithm to do it. Listing the encrypting UA in the host > port is the mechanism to get back to an entity that will be > able to decrypt. There's a RECOMMENDED algorithm? I just went through the document looking for one and I couldn't find it. All I see is something about symmetric keys and Base64 encoding. Where does it name something like DES, or AES, or what have you for encryption? There are also some issues with the mechanism in so far as a trusted entity sends out a chunk of encrypted data in an RPID that only it can decrypt, and then expects entities that want access to this information to 'get back' to them via the given hostname and port. First of all, while it may be specified elsewhere, nothing that I can see in sip-privacy-04 tells me how I can 'get back' to the host that generated the encrypted data. What should I expect is listening on that hostname or port? A SIP server? If so, what sort of request do I send to it (suggesting "please decrypt this string", maybe)? Have any NAT or firewall considerations been taken into account for this? How does the server decide whether or not it should grant you access to the plaintext string? There are a number of issues along these lines... The only alternative to 'getting back' to the host that generated the string doesn't sound like a very well-defined prospect: However, there is also no well-defined way for a downstream (trusted) entity to determine the identity of the calling party, without that entity knowing both the details of how the private "addr-spec" was constructed (crypto algorithm, MAC, encoding, etc.) as well as which key to use for decrypting the information. The solutions to these problems are left as an exercise to the reader, and hence interoperability should not be expected. So I think I will stand by my statement that not enough information about encryption is provided for this to be a viable option. Again, it may be specified elsewhere, but it doesn't seem to be in sip-privacy-04. ---- Next mail > > But anyway, in the quote above I was just making the less ambitious and more > > specific point that 20.9 happens to state that the Call-Info characterizes > > the entity that originated the message, and that this would seem to argue > > against the inclusion of a rpi-pty-type parameter. > > Characterizing the entity that originated the message sounds like *exactly* > what is needed. Subsriber, office-owner, calling-person, instrument, > location - all this is characterizing the entity that originated the > message. Even more general than what is needed. Call-Info allows > a "card" type, so it can also include everything that rfc2426 does > (birthday of the caller???). Um, sorry to be imprecise, by 'characterizes the entity that originated the message' I meant that Call-Info assumes that the originator of the message is the entity described in the Call-Info - so it assumes a single value, effectively, for what the rpi-pty-type would specify for the RPID (whether the RPID characterizes the 'caller' or 'callee' or what have you). I wasn't trying to make a broader statement about Call-Info's vocation. > > True, many other SIP parameters could be misinterpreted to contain > identity information. Just like many are used to offload state > information (as first described in draft-dcsgroup-sip-state). > But since Call-Info has as its stated intent "optional content > presentation to users", it is a far better fit, and hardly abusive. It's not 'optional content presentation', it's 'display optional content'. The difference between the two is that the RPID means "it is important whether or not this information should be displayed to the end user - only do so when the end user is trusted" whereas the Call-Info means "this is unimportant information that the end user should display if they can, otherwise, don't worry about it." > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Peterson, Jon" > To: "'Flemming Andreasen'" , > "Peterson, Jon" > Cc: "'William Marshall'" , sip@ietf.org > Subject: RE: [Sip] Comment, SIP Privacy draft > Date: Fri, 29 Mar 2002 12:33:26 -0600 > > A few notes below. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Friday, March 29, 2002 5:33 AM > > To: Peterson, Jon > > Cc: 'William Marshall'; sip@ietf.org > > Subject: Re: [Sip] Comment, SIP Privacy draft > > > > > > > > > > "Peterson, Jon" wrote: > > > [snip] > > > > OK - so we agree that Call-Info duplicates Remote-Party-Id > functionality > as far > > as this point is concerned. All we need is someone > specifying the usage. > > > > I really hope we all agree that the "proposal" Bill made to > conflate RPID > and Call-Info was not serious, but was intended to make a point about > underspecification in the SIP spec, and also to illustrate > that Call-Info > has its own privacy implications. Right? > > I think it would be problematic to suggest that the Call-Info and RPID > should be conflated, as the remainder of my note bears out. > > [snip] > > > > > > > > Should there be a mechanism in SIP that allows a user agent > > to suggest that > > > proxies treat their requests privately? Of course. I think > > the presence of > > > some sort of privacy flag/header in requests is a > > reasonable way to do so > > > (vide the RPID-Privacy header in sip-privacy today). > > Guaranteeing privacy > > > entails managing a number of headers that could potentially > > divulge identity > > > - Call-Info is one of many examples (the open-ended > > User-Agent and Server > > > headers could also be used as repositories for potentially > > private data, let > > > alone common headers like Via and Contact). > > > > Indeed they could, just like a Remote-Party-Id header can > be used in ways > people > > did not intend to. But why is it, that this must be > obstructed at all cost > in > > the privacy-draft case, but it's perfectly legit in the SIP > spec ? In > fact, if I > > rewrote the privacy-draft to use Call-Info instead of > Remote-Party-Id, > what > > would your arguments now be ? > > > > To limit the scope of the Call-Info, since the Call-Info is > not intended to > be an network-verified identity carriage parameter. Of course. > > This is not 'legit' in the SIP spec. We all know that in the > two-hundred-odd > pages of the SIP spec there are many remaining nits and > gotchas, even when > one is not reading the text in bad faith. This is clearly a bad faith > reading of 20.9. No one would honestly believe that Call-Info > is intended as > a network-verified identitiy carriage mechanism. If that were > proposed, I > believe the authors of bis09 would say that was not a correct usage. > > The real, material difference here is that people want to do > Bad Things with > RPID, and RPID has broadened its definition and its mechanism > to accomodate > these things in the name of privacy. Call-Info is merely > underspecified. > > > > > > > > All that said, I feel that it is somewhat misleading to > suggest that > > > Call-Info and RPID actually have a similar function, or > more directly, > that > > > Call-Info should in fact be replaced with RPID. > > > > Well, I would actually argue the other way. Let's drop > Remote-Party-Id and > just > > use Call-Info since nobody can object to that. > > > > I can object, and I would. Why would anyone fail to object to > that usage? > > > > The note below actually > > > suggests Call-Info could be used to implement a CLIP/CLIR > service - > suffice > > > it to say I do not believe this was the intention behind > 20.9 in bis09. > > > > Ahh, but it could be used in that way - why is there not an > applicability > > statement to make sure it can't be misused ? > > > > Although I already said this above, it is worth reiterating that RPID > purports to be a privacy mechanism, but it has been earmarked > for use in a > number of ways that reflect poorly on privacy. > > [snip differences between RPID and Call-Info] > > > > Well, why on earth are proxies allow to muck with it then ? > Also, why does > it > > talk about "trust that element" ? This all sounds very > familiar to me. > > > > To your first question, I dunno, actually. I mean, I guess I > could see cases > where a service provider wanted to add their homepage HTTP > URI to a request > as it passed as a kind free advertising. Really, those are > the only sorts of > cases I can imagine. > > To you second question, if you get an email from someone that > you don't know > which contains an HTTP URL, should you follow that URL? No, > it could lead > you somewhere you don't want to go, or worse, download some malicious > software. This is all that "trust that element" note is > saying. People have > really chosen to read that in a hostile way. > > [snip] > > > > > > > Hmm, I quote: > > > > "Therefore, it is RECOMMENDED that a UA only render the > information in > the > > Call-Info header field if it can verify the authenticity of > the element > that > > originated the header field and trusts that element." > > > > And your quotation here supports what position, exactly? The > account I gave > above of why you shouldn't follow arbitrary URLs was the > motivation for this > text, as far as I remember, and I read this as consistent > with the above. > > > > > > > > Any resemblance between the two headers further breaks > down when we > begin to > > > look at the functional behavior of RPID - when it is added, how > screening > > > operates, and so forth. The most important difference is > that Call-Info > > > entails no concept of trusted and untrusted networks > which are most > > > certainly entailed by the RPID header. The use of the > RPID header is > > > predicated on the configuration of a set of 'trusted' > destinations which > can > > > inspect the RPID header, and the assumption that it must > be removed if > it is > > > transferred to an untrusted entity. Personally, I don't > think Call-Info > > > requires any such concept if it is used as the spec seems > to intend. > > > > > > > A couple of problems here. First of all the Call-Info talks > about trust > without > > specifying what that is. Secondly, you are talking about > providing privacy > for a > > Call-Info header which you agreed above would be valuable, > so the part > about > > "removing" before forwarding to untrusted entities ends up > being the same > (you > > agreed above that a generic privacy mechanism should cover > Call-Info). > Finally, > > Remote-Party-Id is not supposed to be removed when forwarded to an > untrusted > > entity - it is supposed to be encrypted so we can do call trace. > > > > It's clear to me, anyway, that the 'trust' here is unrelated > to the 'trusted > network' concept in RPID. For one thing, the trust of > Call-Info is a matter > of human oversight. In much the same way that you choose to > follow a URL in > an email or not, you can choose to follow the URL in a > Call-Info - this URL > is intended to be consumed by humans. This is radically > different than the > identity in an RPID. Automatons (proxies) need to decide > programmatically > whether or not they "trust" the next hop to which they are sending > signaling, and groom the RPIDs in messages appropriately. > These two forms of > trust are quite different. > > I see Call-Info as one of many ways that potentially private > information > could be communicated inadvertantly to an end user, so in > that sense I agree > it is valuable for the general SIP privacy mechanism to > discuss Call-Info. > However, I don't think Call-Info should play a role in expressing a > network-verified identity of end-users. > > sip-privacy-04 says 'encrypt or remove', yes. But not enough > information > about encyrption is provided for that to be a viable option - > this isn't > entirely the privacy draft's fault, but sip-privacy-04 could > have said more > than it does, anyway. It is also not clear to me how > 'encryption' helps call > trace. Encryption would only be relevant to call trace in so > far as all > entities that will be able to decrypt the RPIDs are trusted, and that > trusted elements encrypt the RPIDs so that they can pass > through untrusted > entities on the way to some other trusted entity. Encryption > doesn't really > make decisions about trust any easier (which key do I to > encrypt RPIDs when > I send them to an untrusted source? how do I know where the > signaling will > eventually end up?), it just pushes the problem around. > > > > > > > > > The argument that Call-Info is a subset of RPID I also > find a little > > > troublesome - when properly configured quite a few SIP headers, > including at > > > least To and From, could be represented by RPID. With the current > > > extensibility mechanism in sip-privacy-04 I have no doubt > it could be > argued > > > that RPID should replace all other means of asserting > identity in SIP. > > > Personally, I believe this is a defect of sip-privacy-04 > rather than a > > > strength. > > > > Yeah, nothing like the good old smokescreen. Nobody has > suggested the > above so > > let's leave this out - shall we ? > > I am trying to argue in good faith here - this is not meant > to be deceptive, > but rather just to illustrate that if you want to conflate RPID with > Call-Info, there are quite a few other headers you could also > choose to lump > in with those two. It is dangerous to go down that path, I think. > > > > > -- Flemming > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 04:27:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26604 for ; Sat, 30 Mar 2002 04:27:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13966 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 04:27:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12897; Sat, 30 Mar 2002 03:55:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12866 for ; Sat, 30 Mar 2002 03:55:39 -0500 (EST) Received: from mailFA7.rediffmail.com ([202.54.124.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26396 for ; Sat, 30 Mar 2002 03:55:35 -0500 (EST) Received: (qmail 15159 invoked by uid 510); 30 Mar 2002 08:53:39 -0000 Date: 30 Mar 2002 08:53:39 -0000 Message-ID: <20020330085339.15158.qmail@mailFA7.rediffmail.com> Received: from unknown (130.245.9.17) by rediffmail.com via HTTP; 30 Mar 2002 08:53:39 -0000 MIME-Version: 1.0 From: "nitin khosla" Reply-To: "nitin khosla" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] please guide Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi everybody, I am student of SUNY at Stonybrook. I have to do a project on Formal Verification of a protocol. I wanted to work on something which has not been done before. I was searching the net looking for a protocol for few weeks now. I came across this SIP protocol. Can you please guide me if anybody has done Verification/model checking using any tool(murphy,spin,XML..) on this protocol? And it will be nice of you if you could guide me about aspects/properties i can concentrate for verification of this protocol. I will highly appreciate if you could guide this student. thanks, Nitin Khosla _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 05:12:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26837 for ; Sat, 30 Mar 2002 05:11:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15706 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 05:12:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14653; Sat, 30 Mar 2002 04:44:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14621 for ; Sat, 30 Mar 2002 04:44:51 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26688 for ; Sat, 30 Mar 2002 04:44:44 -0500 (EST) Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g2U9hjZ04923; Sat, 30 Mar 2002 03:43:45 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sat, 30 Mar 2002 03:43:40 -0600 Message-ID: <70565611B164D511957A001083FCDD56018701B5@va02.va.neustar.com> From: "Peterson, Jon" To: "'Henning Schulzrinne'" Cc: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Comment, SIP Privacy draft Date: Sat, 30 Mar 2002 03:43:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A few more quick points. Jon Peterson NeuStar, Inc > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 29, 2002 5:36 PM > To: Peterson, Jon > Cc: 'William Marshall'; sip@ietf.org > Subject: Re: [Sip] Comment, SIP Privacy draft > [snip] > > I agree that overloading is harmful, particularly if the trust and > control semantics are different. Call-Info and Alert-Info have no > in-band trust indication or notion as to who can and should insert or > remove it. I find this distinction more important than the difference > between a name and a URL. > I think the proposal is to provide these missing mechanisms in some unstandardized fashion, since there are no restrictions on the extensibility of the Call-Info header, and presumably the control semantics could be proprietary. > > If Call-Info (and maybe other headers) are inserted by the caller, the > issue is "can you trust the information?". If it's inserted by a proxy, > the issue is also "is the proxy allowed to do that, legally speaking?". > > In general, I could see a need for, say, a caller-preferences indication > that would say "don't route my call where my identity is likely to be > revealed". Indeed, caller-preferences may well have suitable mechanism > (preference vs. don't-make-the-call-if-you-can't-oblige) already in > place, only needing the appropriate labels. I think sip-privacy-04 aspires to specify on a per-call basis what degree of privacy the user wishes the network to employ - and this seems like an achievable goal. So, with the RPID-Privacy, the user can dictate whether (and to what degree) the network should restrict identity information about the originator. The only point I was making with regard to privacy concerns is that this mechanism could encompass the Call-Info header, so that, for example, if the user requests degree X of privacy for this call, servers will not insert a Call-Info URL that they might insert otherwise. This could undoubtedly be cast as a caller-preference as well. [snip] > > While I'm not disagreeing with your specific sentiment, I can sympathize > with the frustration of the authors of the "privacy" draft. I would feel > better if we could get away from intent and such, and focus on who > inserts what information where, making sure that the recipient of the > information has enough data to judge the trustworthiness (or knows that > this is always untrustworthy). As long as information doesn't make false > pretenses and misleads implementors and users, intent is just a bit too > much beyond engineering. I think attempts to align any differences > between promises and reality in the draft, as already happening with > wording suggestions regarding "privacy", are more helpful. > Agreed that we shouldn't be dwelling on intent, but rather strict functionality - trying to restrict intent probably won't get us anywhere. > Henning > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 07:42:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28003 for ; Sat, 30 Mar 2002 07:42:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20377 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 07:42:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19351; Sat, 30 Mar 2002 07:11:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19322 for ; Sat, 30 Mar 2002 07:11:55 -0500 (EST) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27754 for ; Sat, 30 Mar 2002 07:11:50 -0500 (EST) Received: from [193.118.192.111] (HELO [193.118.192.80]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000089378; Sat, 30 Mar 2002 12:11:42 +0000 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CA5166E.6B4FBECF@cs.columbia.edu> References: <70565611B164D511957A001083FCDD56018701B1@va02.va.neustar.com> <3CA5166E.6B4FBECF@cs.columbia.edu> Date: Sat, 30 Mar 2002 12:11:30 +0000 To: Henning Schulzrinne From: Lawrence Conroy Subject: Re: [Sip] Comment, SIP Privacy draft Cc: "Jon" , "'William Marshall'" , sip@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 8:35 pm -0500 29/3/02, Henning Schulzrinne wrote: >As a trivial example, for an 800#-call, the calling >number will be inserted and made visible to the callee regardless of >whether the caller likes that feature or not. The caller's only choice >is not to make the call or pay with his own dime. To which I reply:: Hi Henning, Folks, I'm not sure this is correct everywhere. I can make a call to an 0800 number in the U.K. whilst selecting CLIR. Result:: The call center doesn't get my CLI (even though it's used in the free phone service). Equally, due to a particular definition of competition used over here, the CLI may not be passed between TSPs. Finally it is common over here to not present the CLI when a call originates from a PBX (it can be a devil of a job to get the TSP to even present the pilot number). Thus, at least in the U.K., the CLI may be present within a TSP's network, but they may not pass it onwards, or the presentation is suppressed by default. I'm not comfortable with the suggestion that a provider can present data that they have to hand to the destination party. I suspect that this will entertain the regulator for at least a second, prior to the realization that they will have to fill in some paperwork. Note that "the regulator" here need have nothing to do with telecomms - this can be seen as a data protection issue, so affecting data transfer at least across Europe (and to companies that have self-certified the "safe harbour" data protection agreement in the US). Yes, this is NOT the PSTN; yes, I don't want it to be the PSTN; no, it's not technically possible to stop a "bad-faith" intermediary inserting data that as a caller I believe is private; yes, you may WELL find that things work differently outside the US, and finally, yes, in practice there may be a regulatory regime, if only to deal with data protection. Whether this needs anything *within SIP* other than mandatory requirement to carry a caller's privacy preference and to allow a hashed ID that can be recovered on appropriate grounds, I'm not sure. The 0800 example is, however, limited. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 13:37:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03142 for ; Sat, 30 Mar 2002 13:37:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04237 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 13:37:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03197; Sat, 30 Mar 2002 13:11:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03168 for ; Sat, 30 Mar 2002 13:11:48 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02847 for ; Sat, 30 Mar 2002 13:11:46 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2UIB7I12719 for ; Sat, 30 Mar 2002 10:11:07 -0800 (PST) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACT48641; Sat, 30 Mar 2002 10:11:17 -0800 (PST) Date: Sat, 30 Mar 2002 10:08:46 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Summarization of Reason header discussion Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, I haven't heard anything more about the Reason header discussion, so I'm going to summarize what I think we have consensus on. 1) Gonzalo sent a bunch of requirements. Nobody fundamentally challenges that the requirements are wrong or unimportant. We've also seen a few proposed additions. Lots of interesting stuff could reference this work. 2) Dave Oran proposed that we keep a split between the reason a call arrived, and the request history (which contains names). The later has lots of privacy concerns, while the privacy concerns for the former are minimal. I didn't see much in the way of objections here. 3) From a syntax perspective, I think we got agreement that the Reason should always begin with a SIP response code and a textual phrase, but may also include other responses/code families as extra parameters (for example, CPIM error messages, Q.850 error codes, etc.). The motivation is that a SIP device only needs to know about one set of response codes (SIP) to do something appropriate with the Reason, but additional information is available if you care. So, I'd like to find out if folks agree that my summary is accurate, and if we can move forward on defining a Reason header in SIP. thanks, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 16:26:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05112 for ; Sat, 30 Mar 2002 16:26:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10237 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 16:26:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09280; Sat, 30 Mar 2002 16:00:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09238 for ; Sat, 30 Mar 2002 16:00:13 -0500 (EST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04795 for ; Sat, 30 Mar 2002 16:00:09 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.36 2002/03/11 23:18:46 root Exp $) with ESMTP id g2UKnuj14901 for ; Sat, 30 Mar 2002 20:49:56 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.14 2002/03/05 23:31:08 root Exp $) with SMTP id g2UKlIF18824 for ; Sat, 30 Mar 2002 20:47:18 GMT Received: from intel.com ([10.242.97.114]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002033012490603625 for ; Sat, 30 Mar 2002 12:49:06 -0800 Message-ID: <3CA624A1.B0327861@intel.com> Date: Sat, 30 Mar 2002 12:48:33 -0800 From: Francois Lessing X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Can NOTIFY request fork ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have been looking at non-SUBSCRIBE mechanisms to create subscriptions and it seems that the use of such mechanisms mandates the possibility of forking behavior for NOTIFY requests. My reasoning is as follows: The draft allows for non-SUBSCRIBE mechanisms to create subscriptions. This means that a NOTIFY request has to be sent without a dialog being estblished (or at least one cannot assume that the user defined mechnism will create a dialog). If the NOTIFY has to be sent without a dialog being established, a proxy may fork the request. Is there something I missed ? -- Francois Lessing Trillium Digital Systems, a division of Intel Corporation Los Angeles, USA Tel: +1 310 481 5937 Fax: +1 310 481 5558 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Mar 30 16:36:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05281 for ; Sat, 30 Mar 2002 16:36:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10820 for sip-archive@odin.ietf.org; Sat, 30 Mar 2002 16:36:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10066; Sat, 30 Mar 2002 16:22:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10039 for ; Sat, 30 Mar 2002 16:22:52 -0500 (EST) Received: from mailFA4.rediffmail.com ([202.54.124.149]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05054 for ; Sat, 30 Mar 2002 16:22:48 -0500 (EST) Received: (qmail 15012 invoked by uid 510); 30 Mar 2002 21:22:43 -0000 Date: 30 Mar 2002 21:22:43 -0000 Message-ID: <20020330212243.15011.qmail@mailFA4.rediffmail.com> Received: from unknown (130.245.9.17) by rediffmail.com via HTTP; 30 Mar 2002 21:22:43 -0000 MIME-Version: 1.0 From: "nitin khosla" Reply-To: "nitin khosla" To: sip@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi everybody, I am student of SUNY at Stonybrook. I have to do a project on Formal Verification of a protocol. I wanted to work on something which has not been done before. I was searching the net looking for a protocol for few weeks now. I came across this SIP protocol. Can you please guide me if anybody has done Verification/model checking using any tool(murphy,spin,XML..) on this protocol? And it will be nice of you if you could guide me about aspects/properties i can concentrate for verification of this protocol. I will highly appreciate if you could guide this student. thanks, Nitin Khosla _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip