From sip-bounces@ietf.org Fri Jun 01 04:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu268-0002Wh-IE; Fri, 01 Jun 2007 04:03:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hu266-0002W2-QZ for sip-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 04:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu266-0002Vu-65 for sip@ietf.org; Fri, 01 Jun 2007 04:02:58 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu264-0007RY-JE for sip@ietf.org; Fri, 01 Jun 2007 04:02:58 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5182Shw025232; Fri, 1 Jun 2007 11:02:48 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 11:02:19 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 11:02:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Date: Fri, 1 Jun 2007 11:02:18 +0300 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxgIK7Riw References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> From: To: , X-OriginalArrivalTime: 01 Jun 2007 08:02:18.0984 (UTC) FILETIME=[2D0AC680:01C7A423] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have a couple of comments/questions on this draft. 3.2 Policy subscription The MIME type defined in this draft for session-independent policies is application/session-policy+xml. It is mentioned that "a UA compliant to this specification MUST support the User Agent Profile Data Set for Media Policy", which (version -04) seems to define MIME type application/media-policy-dataset+xml. I guess the MIME types should be the same? 4.2 Overview, last sentence=20 It is said that "Both types of policies [applying to the offer, or both to the offer and answer] are supported by session-specific policy mechanism." Does this require a mechanism to indicate in the policy whether the policy applies to offer, or both offer and answer? With this kind of mechanism the endpoint would not have to request a policy decision for the answer, if the policy applies only to the offer. 4.3.1 Offer in request, example on page 12 What should be the behaviour if the policy check at the end (messaages 9 and 10) indicate that the policy was unacceptable? Should there be a re-INVITE or UPDATE, possible triggering a similar policy checking again in the remote end? Would it be better to always wait for the policy decision before answering with the final response? Regards, Simo >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 >Sent: 22.05.2007 01:06 >To: IETF SIP List >Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 > >(As WG chair) > >This is to announce a Working Group Last Call on > >http://www.ietf.org/internet-drafts/draft-ietf-sip-session-poli >cy-framew >ork-01.txt > >The WGLC is for 3 weeks and will end on 11th June 2007. > >Please respond to the editor, and to the SIP mailing list with=20 >comments. > >This WGLC is being held in conjunction with the two related=20 >documents in the SIPPING group, see mail below: > >Regards > >Keith > >--------------------------------------------------------------- >--------- >----------------------------- > >Hi all, > >This is to announce Working Group Last Call on the following documents: >http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-po >licy-data >set-04.txt (Recently updated to address the merging issue=20 >discussed on the mailing list) >http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-p >ackage-03 >.txt (Unchanged since prior to IETF-68) > >This WGLC will end on 11 June 2007. > >Since the WG has previously reviewed these documents, the plan=20 >is to keep the same set of reviewers that previously volunteered:=20 > Bob Penfield, Shida Schubert, Flemming Andreasen, Roni=20 >Even However, anyone additional that would like to volunteer=20 >would be appreciated to get a fresh set of eyes on the document.=20 > >Feedback should be sent to the authors' email addresses (which=20 >is cc'ed using the tools alias in the above for your=20 >convenience) and please copy the SIPPING mailing list. =20 > >Note: the original plan was to WGLC this set of documents=20 >along with the framework document that moved to SIP. So, stay=20 >tuned for an announcement on the SIP list of the WGLC plans=20 >for that document.=20 > >Thanks, >Mary >SIPPING 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=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 01 16:20:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDbK-0006E2-An; Fri, 01 Jun 2007 16:19:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HuDbI-0006Ds-UY for sip-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 16:19:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDbI-0006Dh-Kn for sip@ietf.org; Fri, 01 Jun 2007 16:19:56 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuDbH-0002r9-8G for sip@ietf.org; Fri, 01 Jun 2007 16:19:56 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l51KJlAN026976 for ; Fri, 1 Jun 2007 15:19:54 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:19:36 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:19:36 -0500 Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 15:19:36 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 22:19:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 1 Jun 2007 22:19:32 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> In-Reply-To: <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcejvtZelUhBc4cOStuXV2taJ0iLzgAyuLeA References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 01 Jun 2007 20:19:33.0648 (UTC) FILETIME=[2AF4D900:01C7A48A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Is anyone out there interested in pursuing this? If we did something, it would probably be an update to RFC 3427, and I = don't see an awful lot of WG resources being consumed if we did, i.e. no = impact on our existing workload. However, if we wrote it, would anybody that matters respect it? Does it = solve any current issues? Regards Keith > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Thursday, May 31, 2007 9:01 PM > To: Dean Willis > Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > Hi, Dean, >=20 > > However, RFC 2976 is considered to be somewhat=20 > underspecified, and so =20 > > far the only place we've further specified its usage is in the =20 > > context of transporting binary data for telephony protocol=20 > tunelling. =20 > > We have a standing consensus to NOT use it for arbitrary=20 > data at this =20 > > time. If we were to start using it, we'd need to do something like =20 > > the event-packages model for INFO. So don't use it, and you=20 > won't have to deal with this . . > > . >=20 > This is my understanding also, which makes me wonder why=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > didn't advance - I remember the early 00s as a time of=20 > frantic IETF movement, so maybe things have settled down=20 > enough to confirm the consensus? >=20 > I am more comfortable if we nail down consensus when we can,=20 > rather than pointing people to Jonathan's expired individual=20 > draft for support. >=20 > Other than changing Jonathan's contact information from=20 > Dynamicsoft, were there other updates required? :-) >=20 > Thanks, >=20 > Spencer=20 >=20 >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 02 23:15:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HugYk-0000uK-8A; Sat, 02 Jun 2007 23:15:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HugYi-0000tz-Cv for sip-confirm+ok@megatron.ietf.org; Sat, 02 Jun 2007 23:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HugYi-0000tr-30 for sip@ietf.org; Sat, 02 Jun 2007 23:15:12 -0400 Received: from alnrmhc11.comcast.net ([206.18.177.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HugYg-0003RF-Qp for sip@ietf.org; Sat, 02 Jun 2007 23:15:12 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc11) with ESMTP id <20070603031510b1100g7b4ie>; Sun, 3 Jun 2007 03:15:10 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l533F98t028124 for ; Sat, 2 Jun 2007 23:15:09 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l533F9Cv028120; Sat, 2 Jun 2007 23:15:09 -0400 Date: Sat, 2 Jun 2007 23:15:09 -0400 Message-Id: <200706030315.l533F9Cv028120@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> (drage@alcatel-lucent.com) Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "DRAGE, Keith \(Keith\)" (As WG chair) Is anyone out there interested in pursuing this? What is "this"? Do people think it would be genuinely helpful to finish "this"? If we did something, it would probably be an update to RFC 3427, and I don't see an awful lot of WG resources being consumed if we did, i.e. no impact on our existing workload. However, if we wrote it, would anybody that matters respect it? Does it solve any current issues? Regards Keith > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Thursday, May 31, 2007 9:01 PM > To: Dean Willis > Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > > Hi, Dean, > > > However, RFC 2976 is considered to be somewhat > underspecified, and so > > far the only place we've further specified its usage is in the > > context of transporting binary data for telephony protocol > tunelling. > > We have a standing consensus to NOT use it for arbitrary > data at this > > time. If we were to start using it, we'd need to do something like > > the event-packages model for INFO. So don't use it, and you > won't have to deal with this . . > > . > > This is my understanding also, which makes me wonder why > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > didn't advance - I remember the early 00s as a time of > frantic IETF movement, so maybe things have settled down > enough to confirm the consensus? > > I am more comfortable if we nail down consensus when we can, > rather than pointing people to Jonathan's expired individual > draft for support. > > Other than changing Jonathan's contact information from > Dynamicsoft, were there other updates required? :-) > > Thanks, > > Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 03 15:26:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuviD-0005iA-KK; Sun, 03 Jun 2007 15:26:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HuviC-0005i5-E2 for sip-confirm+ok@megatron.ietf.org; Sun, 03 Jun 2007 15:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuviB-0005ho-Gw for sip@ietf.org; Sun, 03 Jun 2007 15:26:00 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huvi9-0006pk-TF for sip@ietf.org; Sun, 03 Jun 2007 15:25:59 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 169D6205B0; Sun, 3 Jun 2007 21:25:57 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-01-466315c479ca Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EC4A3203DD; Sun, 3 Jun 2007 21:25:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 21:25:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Sun, 3 Jun 2007 21:25:55 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704A645EA@esealmw113.eemea.ericsson.se> In-Reply-To: <200706030315.l533F9Cv028120@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceljXbk7/XFXKyvSR2assTJIUrHZwAc9HhA References: <465E9331.8070909@zesium.com><095901c7a3be$7ace6990$6801a8c0@china.huawei.com><5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <200706030315.l533F9Cv028120@dragon.ariadne.com> From: "Christer Holmberg (JO/LMF)" To: , X-OriginalArrivalTime: 03 Jun 2007 19:25:56.0639 (UTC) FILETIME=[024BBAF0:01C7A615] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I don't think it would be very helpful - at least not if it's supposed = to "forbid" things which are largely depoloyed already (and have been so = for a number of years already). Regards, Christer=20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: 3. kes=E4kuuta 2007 6:15 > To: sip@ietf.org > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > From: "DRAGE, Keith \(Keith\)" >=20 > (As WG chair) >=20 > Is anyone out there interested in pursuing this? >=20 > What is "this"? Do people think it would be genuinely=20 > helpful to finish "this"? >=20 > If we did something, it would probably be an update to RFC 3427, > and I don't see an awful lot of WG resources being consumed if we > did, i.e. no impact on our existing workload. >=20 > However, if we wrote it, would anybody that matters respect it? > Does it solve any current issues? >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > > Sent: Thursday, May 31, 2007 9:01 PM > > To: Dean Willis > > Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings > > Subject: Re: [Sip] INFO message belongs only to INVITE=20 > dialog usage? > >=20 > > Hi, Dean, > >=20 > > > However, RFC 2976 is considered to be somewhat=20 > > underspecified, and so =20 > > > far the only place we've further specified its usage=20 > is in the =20 > > > context of transporting binary data for telephony protocol=20 > > tunelling. =20 > > > We have a standing consensus to NOT use it for arbitrary=20 > > data at this =20 > > > time. If we were to start using it, we'd need to do=20 > something like =20 > > > the event-packages model for INFO. So don't use it, and you=20 > > won't have to deal with this . . > > > . > >=20 > > This is my understanding also, which makes me wonder why=20 > >=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html > > didn't advance - I remember the early 00s as a time of=20 > > frantic IETF movement, so maybe things have settled down=20 > > enough to confirm the consensus? > >=20 > > I am more comfortable if we nail down consensus when we can,=20 > > rather than pointing people to Jonathan's expired individual=20 > > draft for support. > >=20 > > Other than changing Jonathan's contact information from=20 > > Dynamicsoft, were there other updates required? :-) > >=20 > > Thanks, > >=20 > > Spencer=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 03 18:48:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huyrd-0004zR-PU; Sun, 03 Jun 2007 18:47:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Huyrc-0004z9-2P for sip-confirm+ok@megatron.ietf.org; Sun, 03 Jun 2007 18:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huyrb-0004z0-Ow for sip@ietf.org; Sun, 03 Jun 2007 18:47:55 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huyra-00044f-8u for sip@ietf.org; Sun, 03 Jun 2007 18:47:55 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <2007060322475001300j0v14e>; Sun, 3 Jun 2007 22:47:54 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l53Mlo8t026537 for ; Sun, 3 Jun 2007 18:47:50 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l53MlnaX026533; Sun, 3 Jun 2007 18:47:49 -0400 Date: Sun, 3 Jun 2007 18:47:49 -0400 Message-Id: <200706032247.l53MlnaX026533@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <5D1A7985295922448D5550C94DE291800120FE83@DEEXC1U01.de.lucent.com> (drage@alcatel-lucent.com) Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: <7374777208BDC7449D5620EF9423256704739FB3@esealmw113.eemea.ericsson.se> <200705281958.l4SJwNgD021470@dragon.ariadne.com> <7374777208BDC7449D5620EF94232567047C8CF9@esealmw113.eemea.ericsson.se><465B43FD.8040904@cisco.com> <465C252C.6030909@ericsson.com> <7374777208BDC7449D5620EF9423256704805E07@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FD8A@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF942325670483C6E7@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE291800120FE83@DEEXC1U01.de.lucent.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "DRAGE, Keith \(Keith\)" Well, at the moment, what I am trying to do is get some understanding of what we should scope as valid SIP work. I've been busy, so I may be behind in the discussion, but it's not clear to me that there is anything that needs to be done specifically for SIP. I may well be wrong, but my impression is that MIME already has the features and specifications neede so that a receiver can decide whether it has adequately "understood" the document when it only understands some components. These mechanisms are all inherited by SIP and I would expect be a sufficient set of rules. E.g., a UAC that sends a request with a multipart body must expect that some UASs will respond with 415, and have some strategy in place for dealing with that situation. Similarly, a UAC that sends a nested multipart body must expect that some UASs will be unable to process the nested multipart, and will either ignore it or reject the request (as specified), and the UAC must be prepared to deal with that situation. Is there a reason we need to define new, narrower subsets of allowed behaviors and define a SIP mechanism to negotiate these? Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 03 19:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huz75-0006xF-Si; Sun, 03 Jun 2007 19:03:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Huz74-0006xA-8F for sip-confirm+ok@megatron.ietf.org; Sun, 03 Jun 2007 19:03:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huz73-0006x2-Uv for sip@ietf.org; Sun, 03 Jun 2007 19:03:53 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huz72-0006Ln-MT for sip@ietf.org; Sun, 03 Jun 2007 19:03:53 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070603230351m1400flilte>; Sun, 3 Jun 2007 23:03:51 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l53N3o8t027707 for ; Sun, 3 Jun 2007 19:03:50 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l53N3oKS027703; Sun, 3 Jun 2007 19:03:50 -0400 Date: Sun, 3 Jun 2007 19:03:50 -0400 Message-Id: <200706032303.l53N3oKS027703@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> (jbemmel@zonnet.nl) Subject: Re: [Sip] Contact header in 1xx responses/updates remote target ornot? References: <4656BDFE.7020006@zesium.com> <200705260454.l4Q4sYOV027172@dragon.ariadne.com> <000601c79f83$d1f401b0$0601a8c0@BEMBUSTER> X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Jeroen van Bemmel" Not sure if I read your comment right, but RFC3261 12.2.1.2 says When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. It does not say anything about 1xx responses here though... Ack, you're right, I'm wrong. I tried to check but didn't see 12.2.1.2, so I assumed that responses aren't target-refreshing. However, there is a problem that was discussed long ago, which is that a response (except to INVITE) isn't acknowledged, the UAS doesn't know that the UAC has received it, and so doesn't know whether it can abandon listening to its previous target address. So a UA shouldn't use responses to non-INVITE requests to update its target. In regard to 1xx, it seems like a US should use the same contact in 1xx as it does in the 2xx. If the 1xx is not reliable, the UA can't depend on it for target refresh, so the same target refresh must be done in the 2xx. If the 1xx is reliable, the UA can depend on it, but it seems unsafe to then provide a different target address in the 2xx -- which one should be the resulting target? (But upon receiving the PRACK, the UAS does know that it can abandon the previous target.) (Since provisionals and PRACKs are only used in INVITE transactions, final responses are acknowledged, so my first rule of thumb is satisfied.) Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 10:23:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDSo-00063E-1X; Mon, 04 Jun 2007 10:23:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvDSm-000615-AZ for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 10:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDSm-0005zk-0a for sip@ietf.org; Mon, 04 Jun 2007 10:23:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDSk-00049J-Ll for sip@ietf.org; Mon, 04 Jun 2007 10:23:15 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54ENCQd058109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 09:23:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Mon, 4 Jun 2007 09:23:09 -0500 To: "DRAGE, Keith \(Keith\)" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've been getting a lot of offline questions asking for the "right" way to carry information related to the session-usage (often information that's being tunneled around from companion or gatewayed protocols). What we've got sitting around right now is probably not enough if we don't want a new wave of things using INFO. We need at least an easily findable explanation of why with a pointer to which other tools would be better considered for different types of applications. RJS On Jun 1, 2007, at 3:19 PM, DRAGE, Keith ((Keith)) wrote: > (As WG chair) > > Is anyone out there interested in pursuing this? > > If we did something, it would probably be an update to RFC 3427, > and I don't see an awful lot of WG resources being consumed if we > did, i.e. no impact on our existing workload. > > However, if we wrote it, would anybody that matters respect it? > Does it solve any current issues? > > Regards > > Keith > >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >> Sent: Thursday, May 31, 2007 9:01 PM >> To: Dean Willis >> Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings >> Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >> >> Hi, Dean, >> >>> However, RFC 2976 is considered to be somewhat >> underspecified, and so >>> far the only place we've further specified its usage is in the >>> context of transporting binary data for telephony protocol >> tunelling. >>> We have a standing consensus to NOT use it for arbitrary >> data at this >>> time. If we were to start using it, we'd need to do something like >>> the event-packages model for INFO. So don't use it, and you >> won't have to deal with this . . >>> . >> >> This is my understanding also, which makes me wonder why >> http://www.jdrosen.net/papers/draft-rosenberg-sip-info- >> harmful-00.html >> didn't advance - I remember the early 00s as a time of >> frantic IETF movement, so maybe things have settled down >> enough to confirm the consensus? >> >> I am more comfortable if we nail down consensus when we can, >> rather than pointing people to Jonathan's expired individual >> draft for support. >> >> Other than changing Jonathan's contact information from >> Dynamicsoft, were there other updates required? :-) >> >> Thanks, >> >> Spencer >> >> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 11:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvE2s-0001YR-CL; Mon, 04 Jun 2007 11:00:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvE2r-0001YH-1F for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 11:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvE2q-0001Y9-Nz for sip@ietf.org; Mon, 04 Jun 2007 11:00:32 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvE2q-0001GT-Ch for sip@ietf.org; Mon, 04 Jun 2007 11:00:32 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54F0VOu059799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 10:00:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 10:00:29 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, here are a couple of situations that people have repeatedly brought up at SIPits. (Keep in mind that I'm passing this along, not championing any points). 1) Some still have to operate in an environment that has no DNS, even in the core. Their customers are demanding transport=tls to control the use of tls over one hop in this situation. 2) Some have indicated they operate in large enterprise-like networks, where the endpoint has an ephemeral address, one for which there's no way to populate NAPTR/SRVs to indicate a use of TLS when reaching that endpoint. Additionally, the endpoint has a cert (!). They are required to register a contact that causes them to be reached with TLS, and are using transport=tls to do so. RjS On May 31, 2007, at 10:58 AM, Dean Willis wrote: > > A new version of the SIPS draft has been posted: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt > > The author thinks this is ready for last call. I think that, given > the below discussion, it probably is too. But there is one issue > I'm worried about. > > We know it doesn't fix everything, we're not sure it is possible to > fix everything with SIPS, but we are committed to fixing what we > can. So please don't bother to say it isn't worth the effort since > it doesn't make SIPS perfect -- you might be right, but that alone > is insufficient reason to block things. One step at a time. I'm > sure we'll be taking further steps in this space. > > Now, for te issue I'm worried about: > > I have received some personal feedback from more than one credible > source that the draft's direction on transport=tls is inconsistent > with the real world and possibly not optimal. But so far, Juha has > been the only one I've noticed trying to explain this issue "on the > record", and one voice does not overbalance a quiet consensus. So > I'd like to ask the rest of you (if any) who actually feel this way > to step up to the plate and explain what you're talking about, > because I don't get it and it looks like a bunch of the WG doesn't > get it. Please! If you don't step up now, I'm probably going to > make rude "raspberry" noises if you bring it up someplace like > Chicago. > > > -- > Dean (chair hat stapled to head so it doesn't blow off in the > coming storm) > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 11:04:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvE6n-0005nM-9X; Mon, 04 Jun 2007 11:04:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvE6m-0005nG-HX for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 11:04:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvE6m-0005lW-71 for sip@ietf.org; Mon, 04 Jun 2007 11:04:36 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvE6l-0001pd-S6 for sip@ietf.org; Mon, 04 Jun 2007 11:04:36 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54F4Y5T059944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 10:04:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: <465E9331.8070909@zesium.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Mon, 4 Jun 2007 10:04:32 -0500 To: Dean Willis X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Just to polish a rough spot in the thread: >> So my, question is: >> Can INFO message belong to other usages, besides INVITE, such >> are SUBSCRIBE or REFER? >> > > > There was IIRC no intent in the writing of RFC 2976 to restrict > INFO to occurring within an INVITE dialog usage. So it could > technically be used outside of one, including in non-dialog cases. Somebody may have pointed this out already, but 2976 _does_ prevent the use of INFO outside a dialog - bottom of page 4: A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a UAS if the INFO request does not match any existing call leg. > > However, RFC 2976 is considered to be somewhat underspecified, and > so far the only place we've further specified its usage is in the > context of transporting binary data for telephony protocol > tunelling. We have a standing consensus to NOT use it for arbitrary > data at this time. If we were to start using it, we'd need to do > something like the event-packages model for INFO. So don't use it, > and you won't have to deal with this . . . > > > -- > 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 sip-bounces@ietf.org Mon Jun 04 11:09:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEBY-0005nn-64; Mon, 04 Jun 2007 11:09:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvEBX-0005ne-95 for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 11:09:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEBW-0005nW-Vo for sip@ietf.org; Mon, 04 Jun 2007 11:09:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEBV-0002qh-KY for sip@ietf.org; Mon, 04 Jun 2007 11:09:30 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54F9SDo060180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 10:09:28 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <465EE7CF.4010705@cisco.com> References: <465E9331.8070909@zesium.com> <465EE7CF.4010705@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Mon, 4 Jun 2007 10:09:26 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org INFO was written before there _WAS_ anything but an INVITE dialog usage (called a call-leg at the time), so any discussion of its use in other contexts (like SUBSCRIBE) will necessarily be in another document. I remember a strong consensus around it only being allowed in the context of an INVITE usage, but can't find definitive text in any later document this morning. Can anyone else? On May 31, 2007, at 10:20 AM, Paul Kyzivat wrote: > My understanding is consistent with what dialogusage says - INFO is > specific to the INVITE dialog usage. But off the top of my head I > can't recall where that is specified. > > Paul > > Nina Garaca wrote: >> Hi all, >> I have read rfc2976 - The SIP INFO Method, but I haven't really >> understood that INFO message belongs only to INVITE dialog usage, >> which however draft-ietf-sipping-dialogusage-04 claims in its part >> 5.3: >> 5.3. Matching requests to usages >> For many mid-dialog requests, identifying the usage they belong >> to is >> obvious. A dialog can have at most one invite usage, so any >> INVITE, >> UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. >> So my, question is: >> Can INFO message belong to other usages, besides INVITE, such >> are SUBSCRIBE or REFER? >> Thanks in advance, >> Nina. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 12:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEzA-00089s-4l; Mon, 04 Jun 2007 12:00:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvEz7-00087J-ED for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEz7-00087B-3O for sip@ietf.org; Mon, 04 Jun 2007 12:00:45 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEz5-0004Xi-PR for sip@ietf.org; Mon, 04 Jun 2007 12:00:45 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54G0cg27581; Mon, 4 Jun 2007 16:00:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 11:00:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD1D6@zrc2hxm0.corp.nortel.com> In-Reply-To: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: AcejnJ9qmeJaaI2uRfymIzaGx5oDHADI8Zbg References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "SIP IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, May 31, 2007 08:59 > To: SIP IETF > Subject: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? > > I have received some personal feedback from more than one=20 > credible source that the draft's direction on transport=3Dtls=20 > is inconsistent with the real world and possibly not optimal.=20 > But so far, Juha has been the only one I've noticed trying to=20 > explain this issue "on the record", and one voice does not=20 > overbalance a quiet consensus. So I'd like to ask the rest of=20 > you (if any) who actually feel this way to step up to the=20 > plate and explain what you're talking about, because I don't=20 > get it and it looks like a bunch of the WG doesn't get it. =20 > Please! If you don't step up now, I'm probably going to make=20 > rude "raspberry" noises if you bring it up someplace like Chicago. 2 comments and a request... Comment: Indeed, the use of transport=3Dtls seems fairly widespread. 1 However, it is not clear at all to me that it is use consistently accross different implementations. In fact, I'm pretty sure it's not. Comment: The concept of "one hop" with transport=3Dtls is tricky. The presence 2 of transport=3Dtls in a URI would presumably apply to the hop identifying that resource (i.e., the last hop), as opposed to the first hop. Latest draft (-04) discusses this. Request: If people make comments on the use of transport=3Dtls, please be very specific on where you are envisioning it's usage, e.g., Request-URI, Contact in Register, Contact in dialog-creating request, Record-Route, etc. It makes a big difference. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 12:39:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFal-0005W3-Iy; Mon, 04 Jun 2007 12:39:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvFaj-0005TJ-Vu for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 12:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFaj-0005T3-Ln for sip@ietf.org; Mon, 04 Jun 2007 12:39:37 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFai-0000DW-Ae for sip@ietf.org; Mon, 04 Jun 2007 12:39:37 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 42A4D1EC68F; Mon, 4 Jun 2007 19:39:35 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkdCcqavcTNV; Mon, 4 Jun 2007 19:39:33 +0300 (EEST) Received: from taimen (plasmid166.gprs.dnafinland.fi [62.78.124.166]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 19:39:33 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 35E1AAC17F; Mon, 4 Jun 2007 19:39:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.16449.186996.614186@tutpro.com> Date: Mon, 4 Jun 2007 19:39:29 +0300 To: "Francois Audet" Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD1D6@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <1ECE0EB50388174790F9694F77522CCF10BBD1D6@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > Request: If people make comments on the use of transport=tls, please > be very specific on where you are envisioning it's usage, e.g., > Request-URI, Contact in Register, Contact in dialog-creating > request, Record-Route, etc. It makes a big difference. cases where we use transport=tls is in request uri. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 13:29:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGML-0003jL-6f; Mon, 04 Jun 2007 13:28:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvGMJ-0003i3-AS for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 13:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGMJ-0003hr-0W for sip@ietf.org; Mon, 04 Jun 2007 13:28:47 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvGMH-0006bq-JW for sip@ietf.org; Mon, 04 Jun 2007 13:28:46 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54HSVE23625; Mon, 4 Jun 2007 17:28:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 12:28:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> In-Reply-To: <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: AcemuSbKyvROCzoRTVavMLyMxjXmCQAE9iUg References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> From: "Francois Audet" To: "Robert Sparks" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > 1) Some still have to operate in an environment that has no=20 > DNS, even in the core. > Their customers are demanding transport=3Dtls to control=20 > the use of tls over one hop in this situation. Which hop??? UAC -----> Proxy 1 ------> Proxy 2 ------> UAS If you put Request-URI of sip:uas@example.com;transport=3Dtls, to me, it means the link between Proxy 2 and UAS would use TLS. I.e., the parameter would apply to the resource identified in the URI. (I'm assuming Record-Routing is used here). The first hop (between UAC and Proxy 1) is basically what you would select before sending the message (or if a Route header was used, it would be in the Route header). To me, it's self-evident in the actual transport anyways. Everytime I run into this issue, it seems to me that basically what people are asking for is just a way to select TLS for the first hop. We don't need protocol on the wire for this: just a config option in the UAC. > 2) Some have indicated they operate in large enterprise-like=20 > networks, where the endpoint has an ephemeral address, > one for which there's no way to populate NAPTR/SRVs to=20 > indicate a use of TLS when reaching that endpoint. > Additionally, the endpoint has a cert (!). They are=20 > required to register a contact that causes them to be reached > with TLS, and are using transport=3Dtls to do so. Surely they need to register with TLS for this to be secure.=20 The transport could be self-evident again, from the one used while performing the registration. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 14:05:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGvp-00031i-TX; Mon, 04 Jun 2007 14:05:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvGvo-00031a-4t for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGvn-00031S-RP for sip@ietf.org; Mon, 04 Jun 2007 14:05:27 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvGvm-0004Gp-FM for sip@ietf.org; Mon, 04 Jun 2007 14:05:27 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 5B44A1EC68F; Mon, 4 Jun 2007 21:05:25 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7ozuAPDOcNW; Mon, 4 Jun 2007 21:05:22 +0300 (EEST) Received: from taimen (plasmid166.gprs.dnafinland.fi [62.78.124.166]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 21:05:22 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 3CEACAC17F; Mon, 4 Jun 2007 21:05:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.21596.212405.28695@tutpro.com> Date: Mon, 4 Jun 2007 21:05:16 +0300 To: "Francois Audet" Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > Which hop??? > > UAC -----> Proxy 1 ------> Proxy 2 ------> UAS for example, lets say that UAS is pstn gw that needs to be contacted over tls. proxy 1 makes a decision to use this particular pstn gw, rewrites r-uri so that it among other things contains transport=tls parameter, and then forwards the request to proxy 2 that is a "dumb" proxy whose purpose is to front end the gw. i don't know another way to do this because sip uri scheme cannot be upgraded to sips and sips scheme cannot be downgraded to sip. -- 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 sip-bounces@ietf.org Mon Jun 04 14:08:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGya-0006fS-Ge; Mon, 04 Jun 2007 14:08:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvGyZ-0006ZJ-4o for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvGyY-0006ZB-RW for sip@ietf.org; Mon, 04 Jun 2007 14:08:18 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvGyY-0004XB-HV for sip@ietf.org; Mon, 04 Jun 2007 14:08:18 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54I8Hga084125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 13:08:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 13:08:15 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 4, 2007, at 12:28 PM, Francois Audet wrote: >> 1) Some still have to operate in an environment that has no >> DNS, even in the core. >> Their customers are demanding transport=tls to control >> the use of tls over one hop in this situation. > > Which hop??? Any of them - Be sure to notice the lack of DNS there. > > UAC -----> Proxy 1 ------> Proxy 2 ------> UAS How (if they don't have DNS) do they specify the use of TLS between Proxy1 and 2? More specifically - if Proxy1 retargets an initial request to Proxy2 based on either configuration or a registered contact, what's the RURI of the emitted request going to be? Then, what should it record route with? > > If you put Request-URI of sip:uas@example.com;transport=tls, to me, it > means the link between Proxy 2 and UAS would use TLS. I.e., the > parameter would apply to the > resource identified in the URI. (I'm assuming Record-Routing is used > here). > > The first hop (between UAC and Proxy 1) is basically what you would > select before sending the message (or if a Route header was used, it > would be in the Route > header). To me, it's self-evident in the actual transport anyways. I don't understand the last sentence - especially in the record-route/ route case. > > Everytime I run into this issue, it seems to me that basically what > people > are asking for is just a way to select TLS for the first hop. We don't > need > protocol on the wire for this: just a config option in the UAC. This is not what I'm pointing at. > > >> 2) Some have indicated they operate in large enterprise-like >> networks, where the endpoint has an ephemeral address, >> one for which there's no way to populate NAPTR/SRVs to >> indicate a use of TLS when reaching that endpoint. >> Additionally, the endpoint has a cert (!). They are >> required to register a contact that causes them to be reached >> with TLS, and are using transport=tls to do so. > > Surely they need to register with TLS for this to be secure. > The transport could be self-evident again, from the one used > while performing the registration. So the unusual case here is that it _is possible_ (and even meaningful) for the proxy to open a new connection to the UA if the old one is gone. Are you saying that you would like the proxy/registrar to remember that it should use TLS when it did so as a side-effect of the registration arriving over TLS? That would be a way we could go (and we should go all the way and ignore what's in contact altogether if we go here), but you will have to explicitly make 3rd party registration and any registration that installs state that doesn't point exactly to the registering instance illegal. (I know several people think this is a good idea, but I don't think we've made that the official position of the working group yet have we?) 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 sip-bounces@ietf.org Mon Jun 04 14:10:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvH0E-0000go-C3; Mon, 04 Jun 2007 14:10:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvH0D-0000gg-Iz for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvH0D-0000gV-9G for sip@ietf.org; Mon, 04 Jun 2007 14:10:01 -0400 Received: from host10.216.41.24.conversent.net ([216.41.24.10] helo=acmepacket.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvH0B-0004p7-OQ for sip@ietf.org; Mon, 04 Jun 2007 14:10:01 -0400 Received: from BPenfield [10.0.200.6] by acmepacket.com with ESMTP (SMTPD-9.10) id A59B0450; Mon, 04 Jun 2007 14:10:35 -0400 Message-ID: <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> From: "Bob Penfield" To: "Francois Audet" , "Robert Sparks" , "Dean Willis" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Mon, 4 Jun 2007 14:09:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I have seen cases where transport=tls appears in the Record-Route where one hop between proxies uses TLS. For example: UAC---->Proxy1------>Proxy2----->Proxy3----->UAS This is done using a SIP URI (not SIPS). I have not been able to keep up with this discussion, but the question I have is: without transport=tls, how would you express the desire/need to do TLS for a SIP URI in a Record-Route or Route header? I am talking about a case where the proxy (Proxy2 above) supports TCP and TLS, but the selection of transport is made for the initial INVITE, and that same transport needs to be used for in-dialog requests? cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 71 Third Avenue Burlington, MA 01803 bpenfield@acmepacket.com ----- Original Message ----- From: "Francois Audet" To: "Robert Sparks" ; "Dean Willis" Cc: "SIP IETF" Sent: Monday, June 04, 2007 1:28 PM Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? > 1) Some still have to operate in an environment that has no > DNS, even in the core. > Their customers are demanding transport=tls to control > the use of tls over one hop in this situation. Which hop??? UAC -----> Proxy 1 ------> Proxy 2 ------> UAS If you put Request-URI of sip:uas@example.com;transport=tls, to me, it means the link between Proxy 2 and UAS would use TLS. I.e., the parameter would apply to the resource identified in the URI. (I'm assuming Record-Routing is used here). The first hop (between UAC and Proxy 1) is basically what you would select before sending the message (or if a Route header was used, it would be in the Route header). To me, it's self-evident in the actual transport anyways. Everytime I run into this issue, it seems to me that basically what people are asking for is just a way to select TLS for the first hop. We don't need protocol on the wire for this: just a config option in the UAC. > 2) Some have indicated they operate in large enterprise-like > networks, where the endpoint has an ephemeral address, > one for which there's no way to populate NAPTR/SRVs to > indicate a use of TLS when reaching that endpoint. > Additionally, the endpoint has a cert (!). They are > required to register a contact that causes them to be reached > with TLS, and are using transport=tls to do so. Surely they need to register with TLS for this to be secure. The transport could be self-evident again, from the one used while performing the registration. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 14:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvH3q-0003KV-Nx; Mon, 04 Jun 2007 14:13:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvH3p-0003KQ-GD for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvH3p-0003KH-6a for sip@ietf.org; Mon, 04 Jun 2007 14:13:45 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvH3m-0005hs-S6 for sip@ietf.org; Mon, 04 Jun 2007 14:13:45 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54IDgXl084394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 13:13:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <18020.21596.212405.28695@tutpro.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <18020.21596.212405.28695@tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56203AA8-A810-453D-8314-4E7DDD60743C@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 13:13:39 -0500 To: jh@tutpro.com (Juha Heinanen) X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha - The classic answer for this is that the gateway should have a DNS name with its NAPTR and SRV records configured to specify exactly TLS. Do you agree that if you have DNS available, that's good enough? I think you're pointing to specifically the case where you don't have DNS records pointing to UAS, is that correct? RjS On Jun 4, 2007, at 1:05 PM, Juha Heinanen wrote: > Francois Audet writes: > >> Which hop??? >> >> UAC -----> Proxy 1 ------> Proxy 2 ------> UAS > > for example, lets say that UAS is pstn gw that needs to be contacted > over tls. proxy 1 makes a decision to use this particular pstn gw, > rewrites r-uri so that it among other things contains transport=tls > parameter, and then forwards the request to proxy 2 that is a "dumb" > proxy whose purpose is to front end the gw. > > i don't know another way to do this because sip uri scheme cannot be > upgraded to sips and sips scheme cannot be downgraded to sip. > > -- 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 sip-bounces@ietf.org Mon Jun 04 14:30:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHK1-0006g6-8h; Mon, 04 Jun 2007 14:30:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvHJz-0006g1-Sl for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHJz-0006ft-JI for sip@ietf.org; Mon, 04 Jun 2007 14:30:27 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHJy-0007Hn-7X for sip@ietf.org; Mon, 04 Jun 2007 14:30:27 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 96C921EC68F; Mon, 4 Jun 2007 21:30:25 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTEPZ-utpIW5; Mon, 4 Jun 2007 21:30:22 +0300 (EEST) Received: from taimen (plasmid166.gprs.dnafinland.fi [62.78.124.166]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 21:30:22 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 60CF5AC17F; Mon, 4 Jun 2007 21:30:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.23093.372473.844151@tutpro.com> Date: Mon, 4 Jun 2007 21:30:13 +0300 To: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <56203AA8-A810-453D-8314-4E7DDD60743C@nostrum.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <18020.21596.212405.28695@tutpro.com> <56203AA8-A810-453D-8314-4E7DDD60743C@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks writes: > The classic answer for this is that the gateway should have a DNS > name with its NAPTR and SRV > records configured to specify exactly TLS. Do you agree that if you > have DNS available, that's good > enough? it would be good enough if we had client and server srv records separately, but unfortunately we don't. currently there is no dns way to tell "i want my proxy to be contacted by other proxies using tls and by UAs using udp or whatever else. so proxies have to use all kinds configured information to figure out the transport protocol to their peers. -- 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 sip-bounces@ietf.org Mon Jun 04 14:44:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHX6-0002EX-Vs; Mon, 04 Jun 2007 14:44:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvHX5-0002ES-TQ for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHX5-0002EK-Jy for sip@ietf.org; Mon, 04 Jun 2007 14:43:59 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHX4-0000ut-5i for sip@ietf.org; Mon, 04 Jun 2007 14:43:59 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l54IhvGB025766 for ; Mon, 4 Jun 2007 13:43:57 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 13:43:56 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.20]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 20:43:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Date: Mon, 4 Jun 2007 20:43:53 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800124C8F6@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxgK48SWw References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 04 Jun 2007 18:43:54.0229 (UTC) FILETIME=[4D3C4250:01C7A6D8] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A reminder of this current WGLC in progress. If you have comments on this document, it would be appreciated if they are received by the deadline. If you intend to review the document, or think that someone else should have, but have difficulty meeting the deadline, then please send me an email. Otherwise as before, if you have comments, follow the instructions below. Regards Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Monday, May 21, 2007 11:06 PM > To: IETF SIP List > Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 >=20 > (As WG chair) >=20 > This is to announce a Working Group Last Call on >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-pol > icy-framew > ork-01.txt >=20 > The WGLC is for 3 weeks and will end on 11th June 2007. >=20 > Please respond to the editor, and to the SIP mailing list=20 > with comments. >=20 > This WGLC is being held in conjunction with the two related=20 > documents in the SIPPING group, see mail below: >=20 > Regards >=20 > Keith >=20 > -------------------------------------------------------------- > ---------- > ----------------------------- >=20 > Hi all, >=20 > This is to announce Working Group Last Call on the following=20 > documents: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-p > olicy-data > set-04.txt (Recently updated to address the merging issue=20 > discussed on the mailing list) > http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy- > package-03 > .txt (Unchanged since prior to IETF-68) >=20 > This WGLC will end on 11 June 2007. >=20 > Since the WG has previously reviewed these documents, the=20 > plan is to keep the same set of reviewers that previously=20 > volunteered:=20 > Bob Penfield, Shida Schubert, Flemming Andreasen, Roni=20 > Even However, anyone additional that would like to volunteer=20 > would be appreciated to get a fresh set of eyes on the document.=20 >=20 > Feedback should be sent to the authors' email addresses=20 > (which is cc'ed using the tools alias in the above for your=20 > convenience) and please copy the SIPPING mailing list. =20 >=20 > Note: the original plan was to WGLC this set of documents=20 > along with the framework document that moved to SIP. So,=20 > stay tuned for an announcement on the SIP list of the WGLC=20 > plans for that document.=20 >=20 > Thanks, > Mary > SIPPING WG co-chair >=20 > -------------------------------------------------------------- > ---------- > ------------------------------- >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 14:47:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHa8-0003ki-R7; Mon, 04 Jun 2007 14:47:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvHa7-0003kc-7I for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 14:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHa6-0003kU-U5 for sip@ietf.org; Mon, 04 Jun 2007 14:47:06 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHa5-0001Rv-LA for sip@ietf.org; Mon, 04 Jun 2007 14:47:06 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l54Ijir00773; Mon, 4 Jun 2007 18:45:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Mon, 4 Jun 2007 13:46:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> In-Reply-To: <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Thread-Index: Acem05e1UbQ/YwEVTRCHVVwC4fMskAAAILAQ References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> From: "Francois Audet" To: "Bob Penfield" , "Robert Sparks" , "Dean Willis" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > -----Original Message----- > From: Bob Penfield [mailto:BPenfield@acmepacket.com]=20 > Sent: Monday, June 04, 2007 11:10 > To: Audet, Francois (SC100:3055); Robert Sparks; Dean Willis > Cc: SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts ontransport=3Dtls? >=20 > I have seen cases where transport=3Dtls appears in the=20 > Record-Route where one hop between proxies uses TLS. For example: >=20 > UAC---->Proxy1------>Proxy2----->Proxy3----->UAS >=20 > This is done using a SIP URI (not SIPS). >=20 > I have not been able to keep up with this discussion, but the=20 > question I have is: without transport=3Dtls, how would you=20 > express the desire/need to do TLS for a SIP URI in a=20 > Record-Route or Route header? I am talking about a case where=20 > the proxy (Proxy2 above) supports TCP and TLS, but the=20 > selection of transport is made for the initial INVITE, and=20 > that same transport needs to be used for in-dialog requests? I'd say you use no transport parameter in the Record-Route and you do what 3261 recommends, which is to reuse the same TCP connection (TLS on this case) for in-dialog requests. Also, I'd like to point out that since Record-Route is by definition hop by hop, in that case sips would mean exactly the same as=20 transport=3Dtls. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 15:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI2s-0004qz-QO; Mon, 04 Jun 2007 15:16:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvI2r-0004qt-Cl for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:16:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvI2r-0004ql-3C for sip@ietf.org; Mon, 04 Jun 2007 15:16:49 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvI2p-0006YQ-Hn for sip@ietf.org; Mon, 04 Jun 2007 15:16:49 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54JGXE03443; Mon, 4 Jun 2007 19:16:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 14:16:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> In-Reply-To: <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem01ZQKGW3yWbLRIGoYc8wnylbIwABa0Ww References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Monday, June 04, 2007 11:08 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 >=20 > > > > UAC -----> Proxy 1 ------> Proxy 2 ------> UAS >=20 > How (if they don't have DNS) do they specify the use of TLS between > Proxy1 and 2? > More specifically - if Proxy1 retargets an initial request to > Proxy2 based on either > configuration or a registered contact, what's the RURI of=20 > the emitted request going to be? > Then, what should it record route with? I'm not sure I understand what we are trying to achieve here. Say UAC sends initial INVITE. It chooses TLS for transport. No transport parameter. UAC does not use SIPS and therefore does not expect TLS on each hop. Proxy 1 forwards the request to proxy 2. If may or may not use TLS (although it should use TLS if possible). It inserts a Record-Route (or modifies Request-URI). In either cases, it does not need to put a transport parameter. Later, in-dialog request will be sent on each hop reusing the existing established connections (TLS or TCP) as per current RFC 3261=20 procedures. Or are we talking pass each other? > > If you put Request-URI of=20 > sip:uas@example.com;transport=3Dtls, to me, it=20 > > means the link between Proxy 2 and UAS would use TLS. I.e., the=20 > > parameter would apply to the > > resource identified in the URI. (I'm assuming=20 > Record-Routing is used > > here). > > > > The first hop (between UAC and Proxy 1) is basically what you would=20 > > select before sending the message (or if a Route header was=20 > used, it=20 > > would be in the Route header). To me, it's self-evident in=20 > the actual=20 > > transport anyways. >=20 > I don't understand the last sentence - especially in the=20 > record-route/ route case. I'm just saying the first hop is whatever is selected when you sent the message. Since it's the first hop, there the parameter would be useless. > > > > Everytime I run into this issue, it seems to me that basically what=20 > > people are asking for is just a way to select TLS for the=20 > first hop.=20 > > We don't need protocol on the wire for this: just a config=20 > option in=20 > > the UAC. >=20 > This is not what I'm pointing at. I'm trying to understand what you are pointing at. Is it=20 in-dialog requests? Is it forcing a specific hop (not the first or last one) to be TLS, but not all the hops? I think I'm missing something... > > > >> 2) Some have indicated they operate in large enterprise-like=20 > >> networks, where the endpoint has an ephemeral address, > >> one for which there's no way to populate NAPTR/SRVs=20 > to indicate=20 > >> a use of TLS when reaching that endpoint. > >> Additionally, the endpoint has a cert (!). They are=20 > required=20 > >> to register a contact that causes them to be reached > >> with TLS, and are using transport=3Dtls to do so. > > > > Surely they need to register with TLS for this to be secure. > > The transport could be self-evident again, from the one used while=20 > > performing the registration. >=20 > So the unusual case here is that it _is possible_ (and even > meaningful) for the proxy to open a new connection to the UA=20 > if the old one is gone. Are you saying that you would like=20 > the proxy/registrar to remember that it should use TLS when=20 > it did so as a side-effect of the registration arriving over TLS? > > > That would be a way we could go (and we should go all the way=20 > and ignore what's in contact altogether if we go here), but=20 > you will have to explicitly make 3rd party registration and=20 > any registration that installs state that doesn't point=20 > exactly to the registering instance illegal. (I know several=20 > people think this is a good idea, but I don't think we've=20 > made that the official position of the working group yet have we?) I was not thinking specifically of the Mutual-TLS case which is what you are pointing to. In the server-provided certificate case, the client would be responsible to re-establish the TLS connection. The way to do this for server-provided certificate environments is using sip-outbound which does exactly what you said (i.e., ignore the contact). The the registrar doesn't=20 "remember" anything: it just uses existing connections. I tought that was agreed (in Montreal). I don't see any other way to be honest. Now, you do bring up a really good point for environments where people use Mutual-TLS between a proxy and a UA. I guess we could still use an outbound model for this case. Or we could use some indication in the protocol. Not sure it's worth it to add a transport parameter for that. Seems to me to be overly complex, and it wouldn't allow you to indicate that you=20 support many different transport. The third party registration case with the transport parameter is weird to me. It would allow a UA to send a Registration unseculily (over TCP or UDP), and create a binding for a third party using TLS. Seems like it would make the TLS connection pointless (unless somehow the first party is secure some other way). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 15:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvICE-0002zc-Ps; Mon, 04 Jun 2007 15:26:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvICD-0002zX-2L for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:26:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvICC-0002zP-PL for sip@ietf.org; Mon, 04 Jun 2007 15:26:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHzm-0002Wl-Ab for sip@ietf.org; Mon, 04 Jun 2007 15:13:38 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvHzi-0006JD-Oe for sip@ietf.org; Mon, 04 Jun 2007 15:13:38 -0400 Received: by an-out-0708.google.com with SMTP id c17so362403anc for ; Mon, 04 Jun 2007 12:13:33 -0700 (PDT) Received: by 10.101.1.13 with SMTP id d13mr2747620ani.1180984413495; Mon, 04 Jun 2007 12:13:33 -0700 (PDT) Received: by 10.100.141.19 with HTTP; Mon, 4 Jun 2007 12:13:33 -0700 (PDT) Message-ID: <6f9200190706041213i6124ede0t2c9c2e762d904308@mail.gmail.com> Date: Mon, 4 Jun 2007 12:13:33 -0700 From: "Matthew Pease" To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-TMDA-Confirmed: Mon, 04 Jun 2007 15:26:28 -0400 Subject: [Sip] answer a call, caller Id, play info. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all - Not really sure where to post this question as I am just starting to research this issue. We want to allow users to dial into our did voip number. Our service will: 1. get their phone number via caller ID. 2. look up account data with this number. 3. generate a wave file based on the data returned & play it to the user over the established voip link. How might this be done using DID origination and a VOIP stack? Any ideas? Thank you-- Matt Pease ParkingHero, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 15:42:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIR6-0006Ey-Ir; Mon, 04 Jun 2007 15:41:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIR5-0006Ek-E0 for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:41:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIR5-0006Ec-4Z for sip@ietf.org; Mon, 04 Jun 2007 15:41:51 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIR1-0001va-Oi for sip@ietf.org; Mon, 04 Jun 2007 15:41:51 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 4E1571EC68F; Mon, 4 Jun 2007 22:41:46 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxIytMZMWaf4; Mon, 4 Jun 2007 22:41:44 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 22:41:44 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 56701AC145; Mon, 4 Jun 2007 22:41:38 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.27378.227115.453498@tutpro.com> Date: Mon, 4 Jun 2007 22:41:38 +0300 To: "Francois Audet" Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > Later, in-dialog request will be sent on each hop reusing the existing > established connections (TLS or TCP) as per current RFC 3261 > procedures. what if established connection breaks for one reason or another and needs to be re-established for routing in-dialog request? if there is no transport info in request route, how does the proxy know which transport to use? -- 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 sip-bounces@ietf.org Mon Jun 04 15:54:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIcp-00018h-F7; Mon, 04 Jun 2007 15:53:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIcn-00016D-5f for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 15:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIcm-00015S-Lb for sip@ietf.org; Mon, 04 Jun 2007 15:53:56 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIcc-0003ZB-CA for sip@ietf.org; Mon, 04 Jun 2007 15:53:56 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l54JqPr17020; Mon, 4 Jun 2007 19:52:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 14:53:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> In-Reply-To: <18020.27378.227115.453498@tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem4GZwx3iv6XWmRaiL0y0uPMG0dQAANECw References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> From: "Francois Audet" To: "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If it uses Outbound, then connection gets re-established by=20 client automatically (based on keep-alives). Otherwise, correct, you don't know. I guess the real question is "do we need to solve this case"? I guess to me it means that it would be useful only for=20 mutual TLS cases. Is this big enough of a problem to justify the expense of having to deal with the parameter? That's a question for the group. I don't have a strong opinion on it (just a preference for using Outbound for this). > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Monday, June 04, 2007 12:42 > To: Audet, Francois (SC100:3055) > Cc: Robert Sparks; SIP IETF; Dean Willis > Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 > Francois Audet writes: >=20 > > Later, in-dialog request will be sent on each hop reusing=20 > the existing > established connections (TLS or TCP) as per=20 > current RFC 3261 > procedures. >=20 > what if established connection breaks for one reason or=20 > another and needs to be re-established for routing in-dialog=20 > request? if there is no transport info in request route, how=20 > does the proxy know which transport to use? >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 16:03:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvImC-00031Q-35; Mon, 04 Jun 2007 16:03:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvImA-00031K-Sk for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvImA-00031C-JH for sip@ietf.org; Mon, 04 Jun 2007 16:03:38 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIm9-0006RK-8M for sip@ietf.org; Mon, 04 Jun 2007 16:03:38 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 07F581EC68F; Mon, 4 Jun 2007 23:03:36 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA93HqTJ11R6; Mon, 4 Jun 2007 23:03:34 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 23:03:34 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id CF9DCAC145; Mon, 4 Jun 2007 23:03:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.28688.811942.949567@tutpro.com> Date: Mon, 4 Jun 2007 23:03:28 +0300 To: "Francois Audet" Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > I guess the real question is "do we need to solve this case"? > > I guess to me it means that it would be useful only for > mutual TLS cases. Is this big enough of a problem to justify > the expense of having to deal with the parameter? proxy-to-proxy communication is important enough case to justify the transport=tls parameter. -- 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 sip-bounces@ietf.org Mon Jun 04 16:09:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIrr-0004Ud-71; Mon, 04 Jun 2007 16:09:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIrp-0004UK-1r for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIro-0004UC-Od for sip@ietf.org; Mon, 04 Jun 2007 16:09:28 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIrn-0007MB-FM for sip@ietf.org; Mon, 04 Jun 2007 16:09:28 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54K9Px4090825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 15:09:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Mon, 4 Jun 2007 15:09:23 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Bob Penfield , SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What's missing from this, Francois, is how the proxy knows to set up the RR with tls in the first place. i.e. when it retargets how does it _know_ it's retargetting to something over tls vs tcp. I disagree that implementation specific configuration is a good enough answer. I'm happy with the answer "you set this information in DNS" when you have DNS. What I'm not seeing is how you set this when you don't have DNS. RjS On Jun 4, 2007, at 1:46 PM, Francois Audet wrote: >> -----Original Message----- >> From: Bob Penfield [mailto:BPenfield@acmepacket.com] >> Sent: Monday, June 04, 2007 11:10 >> To: Audet, Francois (SC100:3055); Robert Sparks; Dean Willis >> Cc: SIP IETF >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >> thoughts ontransport=tls? >> >> I have seen cases where transport=tls appears in the >> Record-Route where one hop between proxies uses TLS. For example: >> >> UAC---->Proxy1------>Proxy2----->Proxy3----- >> >UAS >> >> This is done using a SIP URI (not SIPS). >> >> I have not been able to keep up with this discussion, but the >> question I have is: without transport=tls, how would you >> express the desire/need to do TLS for a SIP URI in a >> Record-Route or Route header? I am talking about a case where >> the proxy (Proxy2 above) supports TCP and TLS, but the >> selection of transport is made for the initial INVITE, and >> that same transport needs to be used for in-dialog requests? > > I'd say you use no transport parameter in the Record-Route and you > do what 3261 recommends, which is to reuse the same TCP connection > (TLS on this case) for in-dialog requests. > > Also, I'd like to point out that since Record-Route is by definition > hop by hop, in that case sips would mean exactly the same as > transport=tls. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 16:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIui-0005UX-D7; Mon, 04 Jun 2007 16:12:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIuh-0005UR-1R for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIug-0005UI-O2 for sip@ietf.org; Mon, 04 Jun 2007 16:12:26 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIuf-000871-AK for sip@ietf.org; Mon, 04 Jun 2007 16:12:26 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54KCO1F091022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 15:12:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 15:12:22 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 4, 2007, at 2:16 PM, Francois Audet wrote: > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Monday, June 04, 2007 11:08 >> To: Audet, Francois (SC100:3055) >> Cc: Dean Willis; SIP IETF >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >> thoughts on transport=tls? >> >> > >>> >>> UAC -----> Proxy 1 ------> Proxy 2 ------> UAS >> >> How (if they don't have DNS) do they specify the use of TLS between >> Proxy1 and 2? >> More specifically - if Proxy1 retargets an initial request to >> Proxy2 based on either >> configuration or a registered contact, what's the RURI of >> the emitted request going to be? >> Then, what should it record route with? > > I'm not sure I understand what we are trying to achieve here. > > Say UAC sends initial INVITE. > > It chooses TLS for transport. No transport parameter. UAC does not > use SIPS and therefore does not expect TLS on each hop. > > Proxy 1 forwards the request to proxy 2. If may or may not > use TLS (although it should use TLS if possible). It inserts > a Record-Route (or modifies Request-URI). In either cases, it does > not need to put a transport parameter. This is exactly where we are disagreeing. How do you _tell_ P1 that you want to reach P2 using TLS in the first place. As I said elsewhere in the thread, I don't think leaving this unspecified ("you just do this with the configuration of the proxy") is the right answer. If you have DNS, you tell P1 about P2 using DNS. If you don't have DNS, using the transport parameter in the URI you hand it seems pretty natural. That's how you're going to tell it to use udp or tcp... > > Later, in-dialog request will be sent on each hop reusing the existing > established connections (TLS or TCP) as per current RFC 3261 > procedures. > > Or are we talking pass each other? Almost certainly. I hope the above helps us get to a common question. > >>> If you put Request-URI of >> sip:uas@example.com;transport=tls, to me, it >>> means the link between Proxy 2 and UAS would use TLS. I.e., the >>> parameter would apply to the >>> resource identified in the URI. (I'm assuming >> Record-Routing is used >>> here). >>> >>> The first hop (between UAC and Proxy 1) is basically what you would >>> select before sending the message (or if a Route header was >> used, it >>> would be in the Route header). To me, it's self-evident in >> the actual >>> transport anyways. >> >> I don't understand the last sentence - especially in the >> record-route/ route case. > > I'm just saying the first hop is whatever is selected when you > sent the message. Since it's the first hop, there the parameter would > be useless. > >>> >>> Everytime I run into this issue, it seems to me that basically what >>> people are asking for is just a way to select TLS for the >> first hop. >>> We don't need protocol on the wire for this: just a config >> option in >>> the UAC. >> >> This is not what I'm pointing at. > > I'm trying to understand what you are pointing at. Is it > in-dialog requests? Is it forcing a specific hop (not the first or > last one) to be TLS, but not all the hops? > > I think I'm missing something... > > >>> >>>> 2) Some have indicated they operate in large enterprise-like >>>> networks, where the endpoint has an ephemeral address, >>>> one for which there's no way to populate NAPTR/SRVs >> to indicate >>>> a use of TLS when reaching that endpoint. >>>> Additionally, the endpoint has a cert (!). They are >> required >>>> to register a contact that causes them to be reached >>>> with TLS, and are using transport=tls to do so. >>> >>> Surely they need to register with TLS for this to be secure. >>> The transport could be self-evident again, from the one used while >>> performing the registration. >> >> So the unusual case here is that it _is possible_ (and even >> meaningful) for the proxy to open a new connection to the UA >> if the old one is gone. Are you saying that you would like >> the proxy/registrar to remember that it should use TLS when >> it did so as a side-effect of the registration arriving over TLS? >> >> >> That would be a way we could go (and we should go all the way >> and ignore what's in contact altogether if we go here), but >> you will have to explicitly make 3rd party registration and >> any registration that installs state that doesn't point >> exactly to the registering instance illegal. (I know several >> people think this is a good idea, but I don't think we've >> made that the official position of the working group yet have we?) > > I was not thinking specifically of the Mutual-TLS case which is what > you are pointing to. > > In the server-provided certificate case, the client would be > responsible > to re-establish the TLS connection. The way to do this for > server-provided > certificate environments is using sip-outbound which does exactly what > you said (i.e., ignore the contact). The the registrar doesn't > "remember" anything: it just uses existing connections. > > I tought that was agreed (in Montreal). I don't see any other way > to be > honest. > > Now, you do bring up a really good point for environments where people > use Mutual-TLS between a proxy and a UA. I guess we could still use an > outbound > model for this case. Or we could use some indication in the protocol. > Not sure it's worth it to add a transport parameter for that. Seems to > me to > be overly complex, and it wouldn't allow you to indicate that you > support many different transport. > > The third party registration case with the transport parameter is > weird > to > me. It would allow a UA to send a Registration unseculily (over TCP or > UDP), and > create a binding for a third party using TLS. Seems like it would make > the TLS > connection pointless (unless somehow the first party is secure some > other way). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 16:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIvn-000649-Ea; Mon, 04 Jun 2007 16:13:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIvl-00063u-JB for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:13:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIvl-00063m-9k for sip@ietf.org; Mon, 04 Jun 2007 16:13:33 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIvj-0008Af-9i for sip@ietf.org; Mon, 04 Jun 2007 16:13:33 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54KDIp07388; Mon, 4 Jun 2007 20:13:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 15:13:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com> In-Reply-To: <18020.28688.811942.949567@tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem43MAsjm9d93FSbqEBBnxh1n/ZwAACJyw References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> <18020.28688.811942.949567@tutpro.com> From: "Francois Audet" To: "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org But for that, you can use SIPS in Record-Route, no? It would be semantically identical, no? > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com]=20 > Sent: Monday, June 04, 2007 13:03 > To: Audet, Francois (SC100:3055) > Cc: Robert Sparks; SIP IETF; Dean Willis > Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 > Francois Audet writes: >=20 > > I guess the real question is "do we need to solve this case"? > > > > I guess to me it means that it would be useful only for >=20 > mutual TLS cases. Is this big enough of a problem to justify =20 > > the expense of having to deal with the parameter? >=20 > proxy-to-proxy communication is important enough case to=20 > justify the transport=3Dtls parameter. >=20 > -- juha >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 16:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIxr-0006kZ-5h; Mon, 04 Jun 2007 16:15:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvIxn-0006k2-9x for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIxn-0006jr-0K for sip@ietf.org; Mon, 04 Jun 2007 16:15:39 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvIxl-0008L9-L4 for sip@ietf.org; Mon, 04 Jun 2007 16:15:38 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 01AA91EC68F; Mon, 4 Jun 2007 23:15:37 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UHaDbkh7IGz; Mon, 4 Jun 2007 23:15:34 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 23:15:34 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 0BBE8AC145; Mon, 4 Jun 2007 23:15:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.29409.16674.687762@tutpro.com> Date: Mon, 4 Jun 2007 23:15:29 +0300 To: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? In-Reply-To: <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks writes: > I disagree that implementation specific configuration is a good > enough answer. as i wrote earlier, the problem is lack of server srv records, which forces proxy operators to configure (usually in db or radius) what to do with their peers. please first fix server srv records and then you can disagree. -- 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 sip-bounces@ietf.org Mon Jun 04 16:19:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJ1Q-0007w6-PT; Mon, 04 Jun 2007 16:19:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJ1P-0007vS-2n for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:19:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJ1O-0007vJ-PW for sip@ietf.org; Mon, 04 Jun 2007 16:19:22 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJ1N-0000Mc-DX for sip@ietf.org; Mon, 04 Jun 2007 16:19:22 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id C73551EC68F; Mon, 4 Jun 2007 23:19:20 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBp+n6d67KU1; Mon, 4 Jun 2007 23:19:18 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 23:19:18 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id BC3B0AC145; Mon, 4 Jun 2007 23:19:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.29633.731742.38741@tutpro.com> Date: Mon, 4 Jun 2007 23:19:13 +0300 To: "Francois Audet" Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> <18020.28688.811942.949567@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet writes: > But for that, you can use SIPS in Record-Route, no? > It would be semantically identical, no? i don't know and don't care, because i don't use sips uri scheme for anything. it is artificial to imply transport protocol from uri scheme, when there is a way to tell it straight. perhaps someone will later invent some other secure transport protocol to be used with sips when then implication will fail. -- 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 sip-bounces@ietf.org Mon Jun 04 16:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJ1e-00085H-Hd; Mon, 04 Jun 2007 16:19:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJ1d-000854-Hf for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJ1d-00084w-7v for sip@ietf.org; Mon, 04 Jun 2007 16:19:37 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJ1b-0000NW-Uj for sip@ietf.org; Mon, 04 Jun 2007 16:19:37 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54KJYOK091380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 15:19:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <18020.29409.16674.687762@tutpro.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Mon, 4 Jun 2007 15:19:31 -0500 To: jh@tutpro.com (Juha Heinanen) X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis Subject: [Sip] Server srv records? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I don't know what you mean by server srv records. Any name can have SRV records. What distinguishes a server srv record from any other srv record to you? RjS On Jun 4, 2007, at 3:15 PM, Juha Heinanen wrote: > Robert Sparks writes: > >> I disagree that implementation specific configuration is a good >> enough answer. > > as i wrote earlier, the problem is lack of server srv records, which > forces proxy operators to configure (usually in db or radius) what > to do > with their peers. > > please first fix server srv records and then you can disagree. > > -- 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 sip-bounces@ietf.org Mon Jun 04 16:40:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJLw-0001ES-9H; Mon, 04 Jun 2007 16:40:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJLv-0001EK-5x for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJLu-0001EC-Sh for sip@ietf.org; Mon, 04 Jun 2007 16:40:34 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJLt-0003zB-HV for sip@ietf.org; Mon, 04 Jun 2007 16:40:34 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id E322F1EC68F; Mon, 4 Jun 2007 23:40:32 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+OtecFovL97; Mon, 4 Jun 2007 23:40:30 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Mon, 4 Jun 2007 23:40:30 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 77E4DAC145; Mon, 4 Jun 2007 23:40:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.30897.464008.26643@tutpro.com> Date: Mon, 4 Jun 2007 23:40:17 +0300 To: Robert Sparks Subject: [Sip] Server srv records? In-Reply-To: <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks writes: > Any name can have SRV records. What distinguishes a server srv record > from any other srv record to you? xmpp client to server communication uses name _xmpp-client._tcp.example.com and server to server communication nane _xmpp-server._tcp.example.com. this allows different proxies to be used for client-to-server and server-to-server communication. -- 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 sip-bounces@ietf.org Mon Jun 04 16:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJQ2-0006rK-JK; Mon, 04 Jun 2007 16:44:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJQ1-0006rF-0T for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 16:44:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJQ0-0006r7-NL for sip@ietf.org; Mon, 04 Jun 2007 16:44:48 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJPz-0004eH-Df for sip@ietf.org; Mon, 04 Jun 2007 16:44:48 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54KiifM092587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 15:44:45 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <18020.30897.464008.26643@tutpro.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Server srv records? Date: Mon, 4 Jun 2007 15:44:42 -0500 To: jh@tutpro.com (Juha Heinanen) X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ah - that doesn't make sense for SIP in general. You can make it make sense for certain deployments, and what you can do in those cases is give your client facing interface one name and your server facing interface another. Something like _sip._tcp.client-interface.example.com _sip._tcp.server-interface.example.com So, what else are you missing? RjS On Jun 4, 2007, at 3:40 PM, Juha Heinanen wrote: > Robert Sparks writes: > >> Any name can have SRV records. What distinguishes a server srv record >> from any other srv record to you? > > xmpp client to server communication uses name > _xmpp-client._tcp.example.com and server to server communication nane > _xmpp-server._tcp.example.com. this allows different proxies to be > used > for client-to-server and server-to-server communication. > > -- 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 sip-bounces@ietf.org Mon Jun 04 17:04:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjW-0006o0-1V; Mon, 04 Jun 2007 17:04:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJjU-0006nv-Sb for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:04:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjU-0006nn-It for sip@ietf.org; Mon, 04 Jun 2007 17:04:56 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJjT-0007b9-7j for sip@ietf.org; Mon, 04 Jun 2007 17:04:56 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 4A9811EC68F; Tue, 5 Jun 2007 00:04:54 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcGSBZtb6E5w; Tue, 5 Jun 2007 00:04:52 +0300 (EEST) Received: from taimen (primer128.gprs.dnafinland.fi [62.78.125.128]) by tutpro.com (Postfix) with ESMTP; Tue, 5 Jun 2007 00:04:52 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 94644AC145; Tue, 5 Jun 2007 00:04:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.32366.567052.462492@tutpro.com> Date: Tue, 5 Jun 2007 00:04:46 +0300 To: Robert Sparks Subject: Re: [Sip] Server srv records? In-Reply-To: <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert Sparks writes: > Something like > _sip._tcp.client-interface.example.com > _sip._tcp.server-interface.example.com how do you tell your sip client to use the former name its srv queries? in xmpp it is specified that in client srv query, a prefix _xmpp-client prefix is always added to the name. -- 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 sip-bounces@ietf.org Mon Jun 04 17:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjb-0006zy-2Y; Mon, 04 Jun 2007 17:05:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvJja-0006zA-0U for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJjZ-0006yX-HX for sip@ietf.org; Mon, 04 Jun 2007 17:05:01 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvJjY-0007eT-2Q for sip@ietf.org; Mon, 04 Jun 2007 17:05:01 -0400 Received: (qmail 23389 invoked by uid 0); 4 Jun 2007 21:06:15 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Jun 2007 21:06:15 -0000 Message-ID: <006f01c7a6eb$ba7dcb00$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , "Juha Heinanen" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><18020.27378.227115.453498@tutpro.com><1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com><18020.28688.811942.949567@tutpro.com><1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com> <18020.29633.731742.38741@tutpro.com> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Mon, 4 Jun 2007 23:02:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, I believe the issue you are implicitly identifying is the following: it should always be possible to deterministically determine the transport to use towards a next hop learned from a Record-Route header. For a SIPS URI that implies that the 'transport' parameter MUST be present, because (in theory) it could be both TCP and SCTP (ref RFC3261 section 18, where it says "[...] transport protocols like TCP and SCTP, or TLS over those [...]".). It is true that RFC3263 states that TCP SHOULD be used for SIPS in case there is either an explicit port or a numeric IP address, but that does not mean that it _was_ indeed used. And there is nothing in RFC3261 that says proxies MUST support TLS over TCP (it just says TLS and TCP). A stateful proxy/endpoint could maintain state about which transport was used. For these connection oriented transports the connection itself can be used as such, but as you mentioned it may get closed at one point and then the state would be lost. In any case, stateless proxies must be able to determine the transport based on only the URI provided. The use of transport=tls was deprecated for the above reason (SCTP can also go over TLS). So in your case you should be using "sips:host[:port];transport=tcp", there is no implication of transport in that. And RFC3261 should be updated to say that proxies "MUST support TLS over TCP", along with some inconsistencies (e.g. 18.1.1 says "It is 5060 for UDP, TCP and SCTP, 5061 for TLS." while 18.2.1 says "(5060 for TCP and UDP, 5061 for TLS over TCP)" Regards, Jeroen Juha Heinanen wrote: > Francois Audet writes: > >> But for that, you can use SIPS in Record-Route, no? > >> It would be semantically identical, no? > > i don't know and don't care, because i don't use sips uri scheme for > anything. it is artificial to imply transport protocol from uri > scheme, when there is a way to tell it straight. perhaps someone > will later invent some other secure transport protocol to be used > with sips when then implication will fail. > > -- 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 sip-bounces@ietf.org Mon Jun 04 17:22:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK0l-0004le-NG; Mon, 04 Jun 2007 17:22:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvK0k-0004lY-LR for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK0j-0004l8-M9 for sip@ietf.org; Mon, 04 Jun 2007 17:22:46 -0400 Received: from smtp1.versatel.nl ([62.58.50.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK0j-0001oJ-0X for sip@ietf.org; Mon, 04 Jun 2007 17:22:45 -0400 Received: (qmail 32628 invoked by uid 0); 4 Jun 2007 21:24:01 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Jun 2007 21:24:01 -0000 Message-ID: <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Robert Sparks" , "Juha Heinanen" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com><1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com><8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com><18020.29409.16674.687762@tutpro.com><2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com><18020.30897.464008.26643@tutpro.com><839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> Subject: Re: [Sip] Server srv records? Date: Mon, 4 Jun 2007 23:20:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, For clients one would distribute "client-interface.example.com" as the outbound proxy FQDN to use, and upstream proxies would be given "server-interface.example.com" (by using that as domain in AORs). For R-R, the proxy would use "client-interface.example.com" if it performed a location service lookup (i.e. assuming that next hop is then an endpoint), or "server-interface.example.com" otherwise. Nevertheless, in the R-R it would probably be better to be explicit about the transport to use, and not rely on DNS SRV. Then there is no need to worry about client vs server interface protocol preferences, or proxies that use dynamic registration, or DNS SRV misconfiguration or lack of support for it. Regards, Jeroen Juha Heinanen wrote: > Robert Sparks writes: > >> Something like >> _sip._tcp.client-interface.example.com >> _sip._tcp.server-interface.example.com > > how do you tell your sip client to use the former name its srv > queries? in xmpp it is specified that in client srv query, a prefix > _xmpp-client prefix is always added to the name. > > -- 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 sip-bounces@ietf.org Mon Jun 04 17:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK3Y-0007EB-0S; Mon, 04 Jun 2007 17:25:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvK3W-00079w-Bx for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK3W-00078p-26 for sip@ietf.org; Mon, 04 Jun 2007 17:25:38 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK3U-0002kw-N0 for sip@ietf.org; Mon, 04 Jun 2007 17:25:38 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id B6F961EC68F; Tue, 5 Jun 2007 00:25:35 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e-mmwsFtfCm; Tue, 5 Jun 2007 00:25:32 +0300 (EEST) Received: from taimen (plasmid59.gprs.dnafinland.fi [62.78.124.59]) by tutpro.com (Postfix) with ESMTP; Tue, 5 Jun 2007 00:25:32 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id C90FFAC145; Tue, 5 Jun 2007 00:25:26 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18020.33606.332430.139652@tutpro.com> Date: Tue, 5 Jun 2007 00:25:26 +0300 To: "Jeroen van Bemmel" Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? In-Reply-To: <006f01c7a6eb$ba7dcb00$0601a8c0@BEMBUSTER> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com> <18020.28688.811942.949567@tutpro.com> <1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com> <18020.29633.731742.38741@tutpro.com> <006f01c7a6eb$ba7dcb00$0601a8c0@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > The use of transport=tls was deprecated for the above reason (SCTP can also > go over TLS). So in your case you should be using > "sips:host[:port];transport=tcp", there is no implication of transport in > that. jeroen, i agree with the above, but it only solves the r-r case. i cannot use sips + transport=tls as a substitute of transport=tls[/tcp] in request uri because of sips upgrade/downgrade implication. -- 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 sip-bounces@ietf.org Mon Jun 04 17:33:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKAg-0003HZ-RB; Mon, 04 Jun 2007 17:33:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvKAZ-0003Eq-Rf for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKAZ-0003E8-C7 for sip@ietf.org; Mon, 04 Jun 2007 17:32:55 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK8M-0003Eh-Mw for sip@ietf.org; Mon, 04 Jun 2007 17:30:39 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54LUTp02395; Mon, 4 Jun 2007 21:30:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 16:30:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem5K6Djnkh7uheSSSZMVxTLIsV+wAAEY6Q References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > This is exactly where we are disagreeing. >=20 > How do you _tell_ P1 that you want to reach P2 using TLS in=20 > the first place. > As I said elsewhere in the thread, I don't think leaving this=20 > unspecified ("you just do this with the configuration of the=20 > proxy") is the right answer. If you have DNS, you tell P1=20 > about P2 using DNS. If you don't have DNS, using the=20 > transport parameter in the URI you hand it seems pretty=20 > natural. That's how you're going to tell it to use udp or tcp... I think I finally understand what you are saying... Say UAC sends request to Request-URI uas@p2;transport=3Dtls. The transport parameter indicates that the resource in the request URI (uas@p2) is the one that needs to be contacted with TLS. Therefore, it would be the P1 -> P2 link that would use TLS in this case (since P2 owns that domain). And P2 could use whatever=20 it wants for P2 -> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy between P1 and P2) could use whatever they want. The use case would be where the UAC "trust" it own domain and does not feel it necessary to use TLS, and/or the UAC "trusts" the target domain for being responsible of that happens inside the target domain. And finally, the UAC does not really care if there are other types of proxies in the middle (not responsible for a specific domain), that may not use TLS. While I understand that this is in theory something that could be solvable, I'm not sure why it is such an interesting case. Seems to me it is only of value if the only "vulnerable" hop is the one between the source and target domains, and if there are no other proxies between them (e.g., no "Service provider"). In fact, it pretty much describes to me why you should be using SIPS in the first place. Do we *really* want to reintroduce transport=3Dtls for this case? Side note: I just want to point out that RFC 2543 did NOT allow the=20 presence of the transport parameter at all in a Request-URI and 2543 servers would ignore it or remove it.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 17:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKW2-0003nG-Fp; Mon, 04 Jun 2007 17:55:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvKW1-0003ml-18 for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 17:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKW0-0003md-Nk for sip@ietf.org; Mon, 04 Jun 2007 17:55:04 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKW0-00077U-De for sip@ietf.org; Mon, 04 Jun 2007 17:55:04 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54Lt3oH096086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 16:55:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 16:55:01 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok - we're closer, but not quite together yet. Lets start with a different message from the UAC where the RURI is simply sip:something@P1 The authority for something@P1 (the person that might send a register request with that in the To: header) wants requests to go to sip:someapplication@P2 and they want it to go over TLS. What they'd _like_ to do is send a register request with a contact that says to use TLS, or at most, send a single URI to the operators of P1 that describes where to send requests that show up for something@P1. What tools do we give them to make the statement they want to make? RjS On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: >> This is exactly where we are disagreeing. >> >> How do you _tell_ P1 that you want to reach P2 using TLS in >> the first place. >> As I said elsewhere in the thread, I don't think leaving this >> unspecified ("you just do this with the configuration of the >> proxy") is the right answer. If you have DNS, you tell P1 >> about P2 using DNS. If you don't have DNS, using the >> transport parameter in the URI you hand it seems pretty >> natural. That's how you're going to tell it to use udp or tcp... > > > I think I finally understand what you are saying... > > Say UAC sends request to Request-URI uas@p2;transport=tls. > > The transport parameter indicates that the resource in the > request URI (uas@p2) is the one that needs to be contacted with > TLS. Therefore, it would be the P1 -> P2 link that would use > TLS in this case (since P2 owns that domain). And P2 could use > whatever > it wants for P2 -> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to > any > other > proxy between P1 and P2) could use whatever they want. > > The use case would be where the UAC "trust" it own domain and does not > feel it necessary to use TLS, and/or the UAC "trusts" the target > domain > for being responsible of that happens inside the target domain. And > finally, > the UAC does not really care if there are other types of proxies in > the > middle (not responsible for a specific domain), that may not use > TLS. > > While I understand that this is in theory something that could be > solvable, I'm not sure why it is such an interesting case. Seems to me > it is only of value if the only "vulnerable" hop is the one between > the > source and target domains, and if there are no other proxies between > them > (e.g., no "Service provider"). > > In fact, it pretty much describes to me why you should be using > SIPS in > the first place. > > Do we *really* want to reintroduce transport=tls for this case? > > Side note: I just want to point out that RFC 2543 did NOT allow the > presence of the transport parameter at all in a Request-URI and 2543 > servers would ignore it or remove it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 18:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvL8s-0007hY-DC; Mon, 04 Jun 2007 18:35:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvL8q-0007hT-JR for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 18:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvL8q-0007hL-9q for sip@ietf.org; Mon, 04 Jun 2007 18:35:12 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvL8p-0007pj-UC for sip@ietf.org; Mon, 04 Jun 2007 18:35:12 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l54MZ1g13867; Mon, 4 Jun 2007 22:35:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 17:34:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> In-Reply-To: <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem8wO20VjomZcOTBCsNaginLS3kwAAOomg References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Ok, so it has nothing to do with Request-URI then (which is what I tought we were talking about). I don't believe that using transport=3Dtls in Contact for Registration will generally work. There are 2 cases: >From =3D=3D To in REGISTER (First Party Registration) ------------------------------------------------- In this case, if we use SIP-Outbound, we DO already have a solution. With SIP-outbound, the connection used by the registration process is kept alive and reused for both incoming and=20 outgoing requests. It has the advantage that it will support environments=20 where server-provided certificates are used since the TLS connection will only be establishable by the client. A a bonus, SIP-outbound also solves NAT and FW traversal, if=20 there happens to be one. Their proposed solution of using a transport parameter will not work for server-provided certificates as the=20 server will not be able to establish a connection with the client. Since server-provided certificates is by far the most commone deployment scenario (as opposed to=20 Mutual TLS) for UAs, this is a big problem. Their proposed solution wouldn't work either if there is a NAT or Firewall. Again, big problem. Their proposed solution would therefore ONLY be=20 suitable for environments where Mutual TLS is used, and where there are no NATs or Firewall. The SIP-outbound mechanism also works with Mutual TLS. Therefore, for this case, I do not believe that their mechanism is general enough to be standardized. This is described at lenght in the draft. >From !=3D To in REGISTER (Third Party Registration) ------------------------------------------------- Third party registration is problematic for both their proposed solution, as well as for SIP-outbound. For SIP-outbound, well, it plainly doesn't work. For their proposed solution, it is a security problem since it effectively allows a non-secure user (the "authority" as you call it), to request that session be delivered securily. Dr, Evil person could hijack the "authority" role and redirects all sessions to wherever it wants, and the sessions would be "secured" with Dr. Evil. Furthermore, their proposed solution would not work in this=20 case either with server-provided certificates, or if there is a NAT or Firewall. Again, big problem. To me, it means that Third Party Registration is just plain bad in a secure environment.=20 In fact, I don't like the idea of allowing third party=20 registration to allow a UAC with AOR in p1 domain to=20 register a contact in a different domain (p2 in this case). That contact is effectively an AOR.=20 How would I solve the problem?=20 I would expect the other UA (sip:someapplication@P2) to do it's=20 own registration in it's own domain P2, according to the rules of it's own domain. If P2 is using server-provided certificates, it would work (with Outbound). If a NAT is present, it would works as well. Then, I would allow user "something@P1" to log in securily=20 on the Proxy (with HTTPS for example), and request routing to=20 be done to another address (in this case, sip:someapplication@P@). To ensure that P1 would use TLS to P2 (as they want), I'd just put a "User TLS" checkbox. That seems to me to be a lot less broken that trying to squeeze it into third-party REGISTER. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Monday, June 04, 2007 14:55 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 > Ok - we're closer, but not quite together yet. >=20 > Lets start with a different message from the UAC where the=20 > RURI is simply > sip:something@P1 >=20 > The authority for something@P1 (the person that might send a=20 > register request with that in the To: header) wants requests to go to > sip:someapplication@P2 > and they want it to go over TLS. What they'd _like_ to do is=20 > send a register request with a contact that says to use TLS,=20 > or at most, send a single URI to the operators of P1 that=20 > describes where to send requests that show up for something@P1. >=20 > What tools do we give them to make the statement they want to make? >=20 > RjS >=20 >=20 >=20 > On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: >=20 > >> This is exactly where we are disagreeing. > >> > >> How do you _tell_ P1 that you want to reach P2 using TLS=20 > in the first=20 > >> place. > >> As I said elsewhere in the thread, I don't think leaving this=20 > >> unspecified ("you just do this with the configuration of the > >> proxy") is the right answer. If you have DNS, you tell P1 about P2=20 > >> using DNS. If you don't have DNS, using the transport parameter in=20 > >> the URI you hand it seems pretty natural. That's how=20 > you're going to=20 > >> tell it to use udp or tcp... > > > > > > I think I finally understand what you are saying... > > > > Say UAC sends request to Request-URI uas@p2;transport=3Dtls. > > > > The transport parameter indicates that the resource in the=20 > request URI=20 > > (uas@p2) is the one that needs to be contacted with TLS.=20 > Therefore, it=20 > > would be the P1 -> P2 link that would use TLS in this case=20 > (since P2=20 > > owns that domain). And P2 could use whatever it wants for P2 ->=20 > > uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy=20 > > between P1 and P2) could use whatever they want. > > > > The use case would be where the UAC "trust" it own domain=20 > and does not=20 > > feel it necessary to use TLS, and/or the UAC "trusts" the target=20 > > domain for being responsible of that happens inside the=20 > target domain.=20 > > And finally, the UAC does not really care if there are=20 > other types of=20 > > proxies in the middle (not responsible for a specific domain), that=20 > > may not use TLS. > > > > While I understand that this is in theory something that could be=20 > > solvable, I'm not sure why it is such an interesting case.=20 > Seems to me=20 > > it is only of value if the only "vulnerable" hop is the one between=20 > > the source and target domains, and if there are no other proxies=20 > > between them (e.g., no "Service provider"). > > > > In fact, it pretty much describes to me why you should be=20 > using SIPS=20 > > in the first place. > > > > Do we *really* want to reintroduce transport=3Dtls for this case? > > > > Side note: I just want to point out that RFC 2543 did NOT allow the=20 > > presence of the transport parameter at all in a Request-URI=20 > and 2543=20 > > servers would ignore it or remove it. >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 18:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLPd-00082g-15; Mon, 04 Jun 2007 18:52:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvLPb-00082Z-Mi for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 18:52:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLPb-00082P-D2 for sip@ietf.org; Mon, 04 Jun 2007 18:52:31 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLPa-0003BJ-Sk for sip@ietf.org; Mon, 04 Jun 2007 18:52:31 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l54MqSdH098991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Jun 2007 17:52:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 17:52:26 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 4, 2007, at 5:34 PM, Francois Audet wrote: > Ok, so it has nothing to do with Request-URI then (which is what I > tought > we were talking about). Well, we're still not connecting quite yet. It has _EVERYTHING_ to do with Request-URI. It is coincidence that I'm populating what the RURI will be after retargetting with a REGISTER. It could have been any other mechanism. The important part is what comes out into the Request-URI of the P1->P2 link. > > I don't believe that using transport=tls in Contact for > Registration will generally work. (as you read my inline responses below, ask yourself what =tls has to do with what you wrote - I think I can substitute =tcp, which we _do_ allow, and everything but the comments about mutual or server auth still stand) > > There are 2 cases: > > From == To in REGISTER (First Party Registration) > ------------------------------------------------- > > In this case, if we use SIP-Outbound, we DO already > have a solution. Surely you're not suggesting proxies do outbound between them. You're latching onto the endpoint case. I'm talking about a server to server case. > > With SIP-outbound, the connection used by the registration > process is kept alive and reused for both incoming and > outgoing requests. > > It has the advantage that it will support environments > where server-provided certificates are used since > the TLS connection will only be establishable by the > client. > > A a bonus, SIP-outbound also solves NAT and FW traversal, if > there happens to be one. > > Their proposed solution of using a transport parameter > will not work for server-provided certificates as the > server will not be able to establish a connection with > the client. Since server-provided certificates is by far > the most commone deployment scenario (as opposed to > Mutual TLS) for UAs, this is a big problem. > > Their proposed solution wouldn't work either if there is > a NAT or Firewall. Again, big problem. > > Their proposed solution would therefore ONLY be > suitable for environments where Mutual TLS is used, and > where there are no NATs or Firewall. > > The SIP-outbound mechanism also works with Mutual TLS. > > Therefore, for this case, I do not believe that their > mechanism is general enough to be standardized. > > This is described at lenght in the draft. > > > From != To in REGISTER (Third Party Registration) > ------------------------------------------------- > > Third party registration is problematic for both their > proposed solution, as well as for SIP-outbound. > > For SIP-outbound, well, it plainly doesn't work. > > For their proposed solution, it is a security problem > since it effectively allows a non-secure user (the "authority" > as you call it), to request that session be delivered securily. > Dr, Evil person could hijack the "authority" role and redirects > all sessions to wherever it wants, and the sessions would be > "secured" with Dr. Evil. > > Furthermore, their proposed solution would not work in this > case either with server-provided certificates, or if there > is a NAT or Firewall. Again, big problem. > > To me, it means that Third Party Registration is just plain > bad in a secure environment. > > In fact, I don't like the idea of allowing third party > registration to allow a UAC with AOR in p1 domain to > register a contact in a different domain (p2 in this case). > That contact is effectively an AOR. > > How would I solve the problem? > > I would expect the other UA (sip:someapplication@P2) to do it's > own registration in it's own domain P2, according to the rules > of it's > own domain. If P2 is using server-provided certificates, it > would > work (with Outbound). If a NAT is present, it would works as > well. > > Then, I would allow user "something@P1" to log in securily > on the Proxy (with HTTPS for example), and request routing to > be done to another address (in this case, > sip:someapplication@P@). > To ensure that P1 would use TLS to P2 (as they want), I'd just > put > a "User TLS" checkbox. > > That seems to me to be a lot less broken that trying to squeeze > it > into third-party REGISTER. This is getting closer to the P1->P2 hop, but its a bit of a herring that you've separated 1st and 3rd party registration. I could have something@P1 in both to: and from: and still point it at application@P2. I understand where you are going with "make that a checkbox on somebody's GUI" and that's exactly what I'm saying isn't good enough. The preference needs to be reflected in the URI. For the registration case, binding things between P1 and P2, let me try yet another way to say this. It's in the field. People are USING it. We are trying to say "Don't do that" without giving an alternative that works in that scenario. We will be ignored unless we can present a clear and compelling reason why someone is putting life or limb at risk to do this (and I suspect we'll be ignored even then). I'm not sure I can make any such argument around just this transport parameter. If we're going to allow someone to say "udp" or "tcp" in this case, its rather pointless to not let them say tls (with the appropriate caveats around not having the anchor in DNS to verify who you're talking to). I _can_ make an argument around the notion of putting state in that doesn't point directly to you, but that goes way way beyond just the transport parameter, and if we're going to go there, we need to start an entirely different conversation that will take the transport parameter completely off the table for _any_ transport. RjS > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Monday, June 04, 2007 14:55 >> To: Audet, Francois (SC100:3055) >> Cc: Dean Willis; SIP IETF >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >> thoughts on transport=tls? >> >> Ok - we're closer, but not quite together yet. >> >> Lets start with a different message from the UAC where the >> RURI is simply >> sip:something@P1 >> >> The authority for something@P1 (the person that might send a >> register request with that in the To: header) wants requests to go to >> sip:someapplication@P2 >> and they want it to go over TLS. What they'd _like_ to do is >> send a register request with a contact that says to use TLS, >> or at most, send a single URI to the operators of P1 that >> describes where to send requests that show up for something@P1. >> >> What tools do we give them to make the statement they want to make? >> >> RjS >> >> >> >> On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: >> >>>> This is exactly where we are disagreeing. >>>> >>>> How do you _tell_ P1 that you want to reach P2 using TLS >> in the first >>>> place. >>>> As I said elsewhere in the thread, I don't think leaving this >>>> unspecified ("you just do this with the configuration of the >>>> proxy") is the right answer. If you have DNS, you tell P1 about P2 >>>> using DNS. If you don't have DNS, using the transport parameter in >>>> the URI you hand it seems pretty natural. That's how >> you're going to >>>> tell it to use udp or tcp... >>> >>> >>> I think I finally understand what you are saying... >>> >>> Say UAC sends request to Request-URI uas@p2;transport=tls. >>> >>> The transport parameter indicates that the resource in the >> request URI >>> (uas@p2) is the one that needs to be contacted with TLS. >> Therefore, it >>> would be the P1 -> P2 link that would use TLS in this case >> (since P2 >>> owns that domain). And P2 could use whatever it wants for P2 -> >>> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy >>> between P1 and P2) could use whatever they want. >>> >>> The use case would be where the UAC "trust" it own domain >> and does not >>> feel it necessary to use TLS, and/or the UAC "trusts" the target >>> domain for being responsible of that happens inside the >> target domain. >>> And finally, the UAC does not really care if there are >> other types of >>> proxies in the middle (not responsible for a specific domain), that >>> may not use TLS. >>> >>> While I understand that this is in theory something that could be >>> solvable, I'm not sure why it is such an interesting case. >> Seems to me >>> it is only of value if the only "vulnerable" hop is the one between >>> the source and target domains, and if there are no other proxies >>> between them (e.g., no "Service provider"). >>> >>> In fact, it pretty much describes to me why you should be >> using SIPS >>> in the first place. >>> >>> Do we *really* want to reintroduce transport=tls for this case? >>> >>> Side note: I just want to point out that RFC 2543 did NOT allow the >>> presence of the transport parameter at all in a Request-URI >> and 2543 >>> servers would ignore it or remove it. >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 18:57:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLUe-0006TQ-50; Mon, 04 Jun 2007 18:57:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvLUc-0006TK-BJ for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 18:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLUc-0006TC-1F for sip@ietf.org; Mon, 04 Jun 2007 18:57:42 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLUb-0005b4-Kn for sip@ietf.org; Mon, 04 Jun 2007 18:57:42 -0400 Received: (qmail 26834 invoked by uid 0); 4 Jun 2007 22:57:39 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Jun 2007 22:57:39 -0000 Message-ID: <00fd01c7a6fb$7882ab20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><18020.27378.227115.453498@tutpro.com><1ECE0EB50388174790F9694F77522CCF10BBD6C3@zrc2hxm0.corp.nortel.com><18020.28688.811942.949567@tutpro.com><1ECE0EB50388174790F9694F77522CCF10BBD71A@zrc2hxm0.corp.nortel.com><18020.29633.731742.38741@tutpro.com><006f01c7a6eb$ba7dcb00$0601a8c0@BEMBUSTER> <18020.33606.332430.139652@tutpro.com> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughtsontransport=tls? Date: Tue, 5 Jun 2007 00:55:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha (and Francois), What I miss in the discussion and draft is the reason why transport=tls was deprecated, namely that TLS by itself is not a transport. The transport is either TCP or SCTP, TLS is the security layer on top of that The "TLS" value for Via transport in RFC3261 should really be read as "TLS-TCP", just like there is now TLS-SCTP defined in RFC4168. The latter does *not* define a "tls-sctp" value for the 'transport' parameter (i.e. does not extend the definition for 'transport-param'), because it is not needed: the use of TLS is solely determined by the URI scheme "sip" ==> you MAY use TLS (but then upgrade the scheme to "sips:" in the request sent out) "sips"==> you MUST use TLS (with possible exception for last hop, i.e. sips request URI rewritten by proxy to a sip URI obtained from a registered Contact) RFC3261 also implicitly discusses the possibility of a "first hop exception", i.e. a UAC using a "sips:" scheme but not TLS (16.6 point 4). Note that it does not consider the reverse case of using TLS without "sips:" as scheme. Some implementations may use 'transport=tls' for this case, but it is - and should remain - deprecated (i.e. ignored if received, never generated). For received Contact and Record-Route headers, it should be mandatory to maintain state information regarding the transport that was used towards that hop, and whether TLS was used or not. These are 2 separate items. The latter is covered by the "secure" flag in RFC3261, for proxies RFC3261 assumes that "sips <==> use TLS" holds, so there is no need for separate state for proxies regarding the use of TLS. Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 19:22:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLsT-0003wg-AE; Mon, 04 Jun 2007 19:22:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvLsR-0003lW-RJ for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 19:22:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLsR-0003h0-Am for sip@ietf.org; Mon, 04 Jun 2007 19:22:19 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLsP-0002Ga-S0 for sip@ietf.org; Mon, 04 Jun 2007 19:22:19 -0400 Received: (qmail 29903 invoked by uid 0); 4 Jun 2007 23:22:17 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 4 Jun 2007 23:22:17 -0000 Message-ID: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Tue, 5 Jun 2007 01:20:16 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Francois Audet Subject: [Sip] draft-ietf-sip-sips-04: 403 instead of last hop exception X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0299048249==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0299048249== Content-Type: multipart/alternative; boundary="----=_NextPart_000_011E_01C7A70F.AC6310B0" This is a multi-part message in MIME format. ------=_NextPart_000_011E_01C7A70F.AC6310B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In section 4.2 http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt proposes that a proxy should send 403 rather than apply the last hop exception. Instead, I would propose that it would send a 302 with either the registered Contact or the received request URI with a "sip:" scheme. 403 would be confusing, because the caller cannot distinguish between this case and the callee refusing his call. Perhaps a new response code (4xx Unsecure transport not allowed) would be better. Perhaps a caller preference should be defined to request such behavior, similar to "fork" and "no-fork" (RFC3841). Say "no-sips-sip" Regards, Jeroen ------=_NextPart_000_011E_01C7A70F.AC6310B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
In section 4.2 h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt pr= oposes=20 that a proxy should send 403 rather than apply the last hop=20 exception.
 
Instead, I would propose that it would = send a 302=20 with either the registered Contact or the received request URI with a = "sip:"=20 scheme. 403 would be confusing, because the caller cannot distinguish = between=20 this case and the callee refusing his call. Perhaps a new response code = (4xx=20 Unsecure transport not allowed) would be better.
 
Perhaps a caller preference should be = defined to=20 request such behavior, similar to "fork" and "no-fork" = (RFC3841). Say=20 "no-sips-sip"
 
Regards,
Jeroen
------=_NextPart_000_011E_01C7A70F.AC6310B0-- --===============0299048249== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0299048249==-- From sip-bounces@ietf.org Mon Jun 04 19:40:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMAJ-0007fe-0o; Mon, 04 Jun 2007 19:40:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvMAI-0007fZ-7X for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 19:40:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMAH-0007fQ-UK for sip@ietf.org; Mon, 04 Jun 2007 19:40:45 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvMAG-0003Yf-L9 for sip@ietf.org; Mon, 04 Jun 2007 19:40:45 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l54NdWr22321; Mon, 4 Jun 2007 23:39:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2007 18:40:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> In-Reply-To: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-04: 403 instead of last hop exception Thread-Index: Acem/zS71G0v+idiTVWQt46ik72sNwAANtLw References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> From: "Francois Audet" To: "Jeroen van Bemmel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Sip] RE: draft-ietf-sip-sips-04: 403 instead of last hop exception X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, 416 would achieve what you want. 302 would not be backward compatible because some proxy somewhere could recurse on it, resulting in a downgrade. If people prefer a 416, I can put that.=20 I do personaly prefer the 403, because I'd like to avoid any thing that would cause a proxy to "automatically" recurse, thereby resulting in a downgrade. ________________________________ From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Monday, June 04, 2007 16:20 To: sip@ietf.org Cc: Audet, Francois (SC100:3055) Subject: draft-ietf-sip-sips-04: 403 instead of last hop exception =09 =09 In section 4.2 http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt proposes that a proxy should send 403 rather than apply the last hop exception. =20 Instead, I would propose that it would send a 302 with either the registered Contact or the received request URI with a "sip:" scheme. 403 would be confusing, because the caller cannot distinguish between this case and the callee refusing his call. Perhaps a new response code (4xx Unsecure transport not allowed) would be better. =20 Perhaps a caller preference should be defined to request such behavior, similar to "fork" and "no-fork" (RFC3841). Say "no-sips-sip" =20 Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 04 20:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMhx-0006fI-3p; Mon, 04 Jun 2007 20:15:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvMhw-0006fC-57 for sip-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 20:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvMhv-0006f4-Ro for sip@ietf.org; Mon, 04 Jun 2007 20:15:31 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvMhv-0007vO-CO for sip@ietf.org; Mon, 04 Jun 2007 20:15:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l550FIB10487; Tue, 5 Jun 2007 00:15:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Mon, 4 Jun 2007 19:14:47 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> In-Reply-To: <46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: Acem+wt7RQx34ll1THSW3ACql/7fugAB2jQA References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> <46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Robert, I understand what you are saying. And you are right: my point about Third=20 party registration was a red herring: it's really the Contact being=20 different than the source of the REGISTER that is a problem). But frankly, the transport parameter in general IMHO is a problem. The fact that SIP isn't layered properly on top of TCP (or UDP) is the=20 issue frankly. In a world where there are no NATs, no FW and every Joe has it's own user certificate, we could make the transport parameter work. If we re-introduce transport=3Dtls, then we'll have to explain when it will work. We will have to write big caveats that it won't work unless you have no NAT, no Firewall, and you are using Mutual-TLS with User=20 certificates for the UAs. In general, it won't work. In my mind, we would be doing a disservice to the industry by writing protocol to do something that almost never works. The "But I can do it=20 today in the field (but just for TCP)" doesn't hold water, because TLS is not TCP.=20 Furthermore, this "transport=3Dtls" stuff is not documented anywhere in any RFC. So we would be writing from scratch broken procedures to "document" broken practices in the field. Seems insane to me.=20 The clear and compelling reason to not use "transport=3Dtls" is that it won't generally work, except for very contrived scenarios. PS: "Transport=3Dtls" was "deprecated" in RFC 3261, but it didn't exist=20 either in its predecessor RFC 2543. It was only defined in the the draft-ietf-sip-rfc2543bis-00. So the implementations that use it today do not conform to any RCF, obsolete or otherwise. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Monday, June 04, 2007 15:52 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 >=20 > On Jun 4, 2007, at 5:34 PM, Francois Audet wrote: >=20 > > Ok, so it has nothing to do with Request-URI then (which is what I=20 > > tought we were talking about). >=20 > Well, we're still not connecting quite yet. >=20 > It has _EVERYTHING_ to do with Request-URI. >=20 > It is coincidence that I'm populating what the RURI will be=20 > after retargetting with a REGISTER. It could have been any=20 > other mechanism. The important part is what comes out into=20 > the Request-URI of the P1->P2 link. >=20 > > > > I don't believe that using transport=3Dtls in Contact for=20 > Registration=20 > > will generally work. > (as you read my inline responses below, ask yourself what > =3Dtls has to do with what you wrote - I think I can substitute = =3Dtcp, > which we _do_ allow, and everything but the comments about > mutual or server auth still stand) > > > > There are 2 cases: > > > > From =3D=3D To in REGISTER (First Party Registration) > > ------------------------------------------------- > > > > In this case, if we use SIP-Outbound, we DO already > > have a solution. > Surely you're not suggesting proxies do outbound between them. > You're latching onto the endpoint case. I'm talking about a=20 > server to server case. >=20 > > > > With SIP-outbound, the connection used by the registration > > process is kept alive and reused for both incoming and > > outgoing requests. > > > > It has the advantage that it will support environments > > where server-provided certificates are used since > > the TLS connection will only be establishable by the > > client. > > > > A a bonus, SIP-outbound also solves NAT and FW traversal, if > > there happens to be one. > > > > Their proposed solution of using a transport parameter > > will not work for server-provided certificates as the > > server will not be able to establish a connection with > > the client. Since server-provided certificates is by far > > the most commone deployment scenario (as opposed to > > Mutual TLS) for UAs, this is a big problem. > > > > Their proposed solution wouldn't work either if there is > > a NAT or Firewall. Again, big problem. > > > > Their proposed solution would therefore ONLY be > > suitable for environments where Mutual TLS is used, and > > where there are no NATs or Firewall. > > > > The SIP-outbound mechanism also works with Mutual TLS. > > > > Therefore, for this case, I do not believe that their > > mechanism is general enough to be standardized. > > > > This is described at lenght in the draft. > > > > > > From !=3D To in REGISTER (Third Party Registration) > > ------------------------------------------------- > > > > Third party registration is problematic for both their > > proposed solution, as well as for SIP-outbound. > > > > For SIP-outbound, well, it plainly doesn't work. > > > > For their proposed solution, it is a security problem > > since it effectively allows a non-secure user (the "authority" > > as you call it), to request that session be delivered securily. > > Dr, Evil person could hijack the "authority" role and redirects > > all sessions to wherever it wants, and the sessions would be > > "secured" with Dr. Evil. > > > > Furthermore, their proposed solution would not work in this > > case either with server-provided certificates, or if there > > is a NAT or Firewall. Again, big problem. > > > > To me, it means that Third Party Registration is just plain > > bad in a secure environment. > > > > In fact, I don't like the idea of allowing third party > > registration to allow a UAC with AOR in p1 domain to > > register a contact in a different domain (p2 in this case). > > That contact is effectively an AOR. > > > > How would I solve the problem? > > > > I would expect the other UA (sip:someapplication@P2) to do it's > > own registration in it's own domain P2, according to the rules > > of it's > > own domain. If P2 is using server-provided certificates, it > > would > > work (with Outbound). If a NAT is present, it would works as > > well. > > > > Then, I would allow user "something@P1" to log in securily > > on the Proxy (with HTTPS for example), and request routing to > > be done to another address (in this case, > > sip:someapplication@P@). > > To ensure that P1 would use TLS to P2 (as they want), I'd just > > put > > a "User TLS" checkbox. > > > > That seems to me to be a lot less broken that trying to squeeze > > it > > into third-party REGISTER. >=20 > This is getting closer to the P1->P2 hop, but its a bit of a herring =20 > that > you've separated 1st and 3rd party registration. I could have =20 > something@P1 > in both to: and from: and still point it at application@P2. >=20 > I understand where you are going with "make that a checkbox on =20 > somebody's GUI" and > that's exactly what I'm saying isn't good enough. The preference =20 > needs to be reflected in the URI. >=20 > For the registration case, binding things between P1 and P2, let me =20 > try yet another way to say this. >=20 > It's in the field. > People are USING it. > We are trying to say "Don't do that" without giving an alternative =20 > that works in that scenario. > We will be ignored unless we can present a clear and compelling =20 > reason why someone > is putting life or limb at risk to do this (and I suspect we'll be =20 > ignored even then). >=20 > I'm not sure I can make any such argument around just this transport =20 > parameter. If we're > going to allow someone to say "udp" or "tcp" in this case,=20 > its rather =20 > pointless to not let them > say tls (with the appropriate caveats around not having the=20 > anchor in =20 > DNS to verify who > you're talking to). >=20 > I _can_ make an argument around the notion of putting state in that =20 > doesn't point directly to you, > but that goes way way beyond just the transport parameter, and if =20 > we're going to go there, we > need to start an entirely different conversation that will take the =20 > transport parameter completely > off the table for _any_ transport. >=20 > RjS >=20 > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Monday, June 04, 2007 14:55 > >> To: Audet, Francois (SC100:3055) > >> Cc: Dean Willis; SIP IETF > >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > >> thoughts on transport=3Dtls? > >> > >> Ok - we're closer, but not quite together yet. > >> > >> Lets start with a different message from the UAC where the > >> RURI is simply > >> sip:something@P1 > >> > >> The authority for something@P1 (the person that might send a > >> register request with that in the To: header) wants=20 > requests to go to > >> sip:someapplication@P2 > >> and they want it to go over TLS. What they'd _like_ to do is > >> send a register request with a contact that says to use TLS, > >> or at most, send a single URI to the operators of P1 that > >> describes where to send requests that show up for something@P1. > >> > >> What tools do we give them to make the statement they want to make? > >> > >> RjS > >> > >> > >> > >> On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: > >> > >>>> This is exactly where we are disagreeing. > >>>> > >>>> How do you _tell_ P1 that you want to reach P2 using TLS > >> in the first > >>>> place. > >>>> As I said elsewhere in the thread, I don't think leaving this > >>>> unspecified ("you just do this with the configuration of the > >>>> proxy") is the right answer. If you have DNS, you tell=20 > P1 about P2 > >>>> using DNS. If you don't have DNS, using the transport=20 > parameter in > >>>> the URI you hand it seems pretty natural. That's how > >> you're going to > >>>> tell it to use udp or tcp... > >>> > >>> > >>> I think I finally understand what you are saying... > >>> > >>> Say UAC sends request to Request-URI uas@p2;transport=3Dtls. > >>> > >>> The transport parameter indicates that the resource in the > >> request URI > >>> (uas@p2) is the one that needs to be contacted with TLS. > >> Therefore, it > >>> would be the P1 -> P2 link that would use TLS in this case > >> (since P2 > >>> owns that domain). And P2 could use whatever it wants for P2 -> > >>> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy > >>> between P1 and P2) could use whatever they want. > >>> > >>> The use case would be where the UAC "trust" it own domain > >> and does not > >>> feel it necessary to use TLS, and/or the UAC "trusts" the target > >>> domain for being responsible of that happens inside the > >> target domain. > >>> And finally, the UAC does not really care if there are > >> other types of > >>> proxies in the middle (not responsible for a specific=20 > domain), that > >>> may not use TLS. > >>> > >>> While I understand that this is in theory something that could be > >>> solvable, I'm not sure why it is such an interesting case. > >> Seems to me > >>> it is only of value if the only "vulnerable" hop is the=20 > one between > >>> the source and target domains, and if there are no other proxies > >>> between them (e.g., no "Service provider"). > >>> > >>> In fact, it pretty much describes to me why you should be > >> using SIPS > >>> in the first place. > >>> > >>> Do we *really* want to reintroduce transport=3Dtls for this case? > >>> > >>> Side note: I just want to point out that RFC 2543 did NOT=20 > allow the > >>> presence of the transport parameter at all in a Request-URI > >> and 2543 > >>> servers would ignore it or remove it. > >> > >> >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 05:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVK3-0006QU-On; Tue, 05 Jun 2007 05:27:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvVK2-0006Np-Oe for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 05:27:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVK2-0006Nb-Ck for sip@ietf.org; Tue, 05 Jun 2007 05:27:26 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVK0-0007s3-Tj for sip@ietf.org; Tue, 05 Jun 2007 05:27:26 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l559QShF016052; Tue, 5 Jun 2007 11:26:28 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS04.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 11:27:22 +0200 Message-ID: <46652C76.50908@alcatel-lucent.fr> Date: Tue, 05 Jun 2007 11:27:18 +0200 From: Thomas Froment User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Server srv records? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com><1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com><8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com><18020.29409.16674.687762@tutpro.com><2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com><18020.30897.464008.26643@tutpro.com><839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> In-Reply-To: <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 09:27:22.0065 (UTC) FILETIME=[B85E2410:01C7A753] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Bob Penfield , SIP IETF , Francois Audet , Juha Heinanen , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Juha, > > For clients one would distribute "client-interface.example.com" as the > outbound proxy FQDN to use, and upstream proxies would be given > "server-interface.example.com" (by using that as domain in AORs). > > For R-R, the proxy would use "client-interface.example.com" if it > performed a location service lookup (i.e. assuming that next hop is > then an endpoint), or "server-interface.example.com" otherwise. > > Nevertheless, in the R-R it would probably be better to be explicit > about the transport to use, and not rely on DNS SRV. Then there is no > need to worry about client vs server interface protocol preferences, > or proxies that use dynamic registration, or DNS SRV misconfiguration > or lack of support for it. I agree with the last point, but does everybody agree? I would really like to know because this exactly the type of scenario I would like to see clarified in draft-froment-sip-record-route-fix-00... Thomas _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 05:39:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVVg-0005UN-7f; Tue, 05 Jun 2007 05:39:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvVVf-0005LQ-5U for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 05:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVVe-0005Hy-Oa for sip@ietf.org; Tue, 05 Jun 2007 05:39:26 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVVc-0001IY-Ps for sip@ietf.org; Tue, 05 Jun 2007 05:39:26 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l559crbQ025240; Tue, 5 Jun 2007 12:39:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:39:07 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 12:39:07 +0300 Received: from [172.21.41.239] (esdhcp041239.research.nokia.com [172.21.41.239]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l559d4E5008131; Tue, 5 Jun 2007 12:39:05 +0300 Message-ID: <46652F39.8060001@nokia.com> Date: Tue, 05 Jun 2007 12:39:05 +0300 From: Aki Niemi User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: ext Robert Sparks Subject: Re: [Sip] Server srv records? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> In-Reply-To: <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 09:39:07.0312 (UTC) FILETIME=[5CBA4B00:01C7A755] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Bob Penfield , SIP IETF , Juha Heinanen , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Robert Sparks wrote: > Ah - that doesn't make sense for SIP in general. I rather think it makes perfect sense. With sip-outbound we have what in practical terms are two different SIP interfaces already; a client-server interface for UAs that REGISTER to the domain, and a server-server interface for outside-in traffic like INVITEs from other UAs (read: servers by whom other UAs send their sip-identity signed traffic). > You can make it make sense for certain deployments, and what you can do > in those cases > is give your client facing interface one name and your server facing > interface another. > > Something like > _sip._tcp.client-interface.example.com > _sip._tcp.server-interface.example.com > > So, what else are you missing? A standard mechanism to configure the UAs of your domain to use _sip._tcp.client-interface.example.com, while the rest of the world uses _sip._tcp.server-interface.example.com. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 09:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZM0-0001AI-Nh; Tue, 05 Jun 2007 09:45:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvZLz-00019r-24 for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 09:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZLy-00019j-MU for sip@ietf.org; Tue, 05 Jun 2007 09:45:42 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZLx-00078p-A2 for sip@ietf.org; Tue, 05 Jun 2007 09:45:42 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id BC7C61EC68F; Tue, 5 Jun 2007 16:45:39 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rri+qNZyF4Se; Tue, 5 Jun 2007 16:45:37 +0300 (EEST) Received: from taimen (primer151.gprs.dnafinland.fi [62.78.125.151]) by tutpro.com (Postfix) with ESMTP; Tue, 5 Jun 2007 16:45:37 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 4CF81AC145; Tue, 5 Jun 2007 16:45:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18021.26876.281550.48449@tutpro.com> Date: Tue, 5 Jun 2007 16:45:32 +0300 To: "Jeroen van Bemmel" Subject: Re: [Sip] Server srv records? In-Reply-To: <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > For clients one would distribute "client-interface.example.com" as the > outbound proxy FQDN to use, and upstream proxies would be given > "server-interface.example.com" (by using that as domain in AORs). i don't get this. the domain of SIP UAs' SIP uris is example.com for which the queries are done, not something else. clients would need to prefix that with _sip-client and servers with _sip-server. currently there is no standard for 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 sip-bounces@ietf.org Tue Jun 05 09:48:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZP6-000275-QP; Tue, 05 Jun 2007 09:48:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvZP4-00026x-ME for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 09:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZP4-00026k-CK for sip@ietf.org; Tue, 05 Jun 2007 09:48:54 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZP3-0007aX-Og for sip@ietf.org; Tue, 05 Jun 2007 09:48:54 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l55Dmqbi043343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jun 2007 08:48:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> <46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Tue, 5 Jun 2007 08:48:49 -0500 To: "Francois Audet" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 4, 2007, at 7:14 PM, Francois Audet wrote: > Hi Robert, > > I understand what you are saying. And you are right: my point about > Third > party registration was a red herring: it's really the Contact being > different than the source of the REGISTER that is a problem). > > But frankly, the transport parameter in general IMHO is a problem. The > fact that SIP isn't layered properly on top of TCP (or UDP) is the > issue frankly. > > In a world where there are no NATs, no FW and every Joe has it's own > user certificate, we could make the transport parameter work. > > If we re-introduce transport=tls, then we'll have to explain when it > will > work. We will have to write big caveats that it won't work unless you > have no NAT, no Firewall, and you are using Mutual-TLS with User > certificates for the UAs. In general, it won't work. So I understand your position on how this affects devices we expect to be behind transport-destroying elements and that we don't expect to generally have certificates. What about the proxy->proxy (or some stable network server) hop, where we expect there _isn't_ a transport-destroying intermediary (hah) and that we expect they _do_ have certificates? This is the case where I think we have a real constituency (with real applications) that we're harming. Consider the routing decision that P1 needs to make. The tools we have allow P1 to choose among the protocols it knows how to use by administrative configuration. They let P2 express policy about which protocols P1 should use (through DNS). What they don't do is let P1 choose between protocols based on a user's (or application's) input. We've got this concept of a location service that you access using REGISTER. The spec talks about running it separately from a proxy - so consider the case where a proxy either does query REGISTERs or sends a request to a redirect server to figure out where it's supposed to go. What it gets back is URIs in Contact header fields. How can the location service tell the proxy that's asking for a routing decision that "for this input URI, goto this output URI and use TLS"? RjS > > In my mind, we would be doing a disservice to the industry by writing > protocol to do something that almost never works. The "But I can do it > today in the field (but just for TCP)" doesn't hold water, because TLS > is not TCP. > > Furthermore, this "transport=tls" stuff is not documented anywhere in > any RFC. So we would be writing from scratch broken procedures to > "document" broken practices in the field. Seems insane to me. > > The clear and compelling reason to not use "transport=tls" is that it > won't generally work, except for very contrived scenarios. > > PS: "Transport=tls" was "deprecated" in RFC 3261, but it didn't exist > either in its predecessor RFC 2543. It was only defined in the > the draft-ietf-sip-rfc2543bis-00. So the implementations that use > it today do not conform to any RCF, obsolete or otherwise. > > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Monday, June 04, 2007 15:52 >> To: Audet, Francois (SC100:3055) >> Cc: Dean Willis; SIP IETF >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >> thoughts on transport=tls? >> >> >> On Jun 4, 2007, at 5:34 PM, Francois Audet wrote: >> >>> Ok, so it has nothing to do with Request-URI then (which is what I >>> tought we were talking about). >> >> Well, we're still not connecting quite yet. >> >> It has _EVERYTHING_ to do with Request-URI. >> >> It is coincidence that I'm populating what the RURI will be >> after retargetting with a REGISTER. It could have been any >> other mechanism. The important part is what comes out into >> the Request-URI of the P1->P2 link. >> >>> >>> I don't believe that using transport=tls in Contact for >> Registration >>> will generally work. >> (as you read my inline responses below, ask yourself what >> =tls has to do with what you wrote - I think I can substitute =tcp, >> which we _do_ allow, and everything but the comments about >> mutual or server auth still stand) >>> >>> There are 2 cases: >>> >>> From == To in REGISTER (First Party Registration) >>> ------------------------------------------------- >>> >>> In this case, if we use SIP-Outbound, we DO already >>> have a solution. >> Surely you're not suggesting proxies do outbound between them. >> You're latching onto the endpoint case. I'm talking about a >> server to server case. >> >>> >>> With SIP-outbound, the connection used by the registration >>> process is kept alive and reused for both incoming and >>> outgoing requests. >>> >>> It has the advantage that it will support environments >>> where server-provided certificates are used since >>> the TLS connection will only be establishable by the >>> client. >>> >>> A a bonus, SIP-outbound also solves NAT and FW traversal, if >>> there happens to be one. >>> >>> Their proposed solution of using a transport parameter >>> will not work for server-provided certificates as the >>> server will not be able to establish a connection with >>> the client. Since server-provided certificates is by far >>> the most commone deployment scenario (as opposed to >>> Mutual TLS) for UAs, this is a big problem. >>> >>> Their proposed solution wouldn't work either if there is >>> a NAT or Firewall. Again, big problem. >>> >>> Their proposed solution would therefore ONLY be >>> suitable for environments where Mutual TLS is used, and >>> where there are no NATs or Firewall. >>> >>> The SIP-outbound mechanism also works with Mutual TLS. >>> >>> Therefore, for this case, I do not believe that their >>> mechanism is general enough to be standardized. >>> >>> This is described at lenght in the draft. >>> >>> >>> From != To in REGISTER (Third Party Registration) >>> ------------------------------------------------- >>> >>> Third party registration is problematic for both their >>> proposed solution, as well as for SIP-outbound. >>> >>> For SIP-outbound, well, it plainly doesn't work. >>> >>> For their proposed solution, it is a security problem >>> since it effectively allows a non-secure user (the "authority" >>> as you call it), to request that session be delivered securily. >>> Dr, Evil person could hijack the "authority" role and redirects >>> all sessions to wherever it wants, and the sessions would be >>> "secured" with Dr. Evil. >>> >>> Furthermore, their proposed solution would not work in this >>> case either with server-provided certificates, or if there >>> is a NAT or Firewall. Again, big problem. >>> >>> To me, it means that Third Party Registration is just plain >>> bad in a secure environment. >>> >>> In fact, I don't like the idea of allowing third party >>> registration to allow a UAC with AOR in p1 domain to >>> register a contact in a different domain (p2 in this case). >>> That contact is effectively an AOR. >>> >>> How would I solve the problem? >>> >>> I would expect the other UA (sip:someapplication@P2) to do it's >>> own registration in it's own domain P2, according to the rules >>> of it's >>> own domain. If P2 is using server-provided certificates, it >>> would >>> work (with Outbound). If a NAT is present, it would works as >>> well. >>> >>> Then, I would allow user "something@P1" to log in securily >>> on the Proxy (with HTTPS for example), and request routing to >>> be done to another address (in this case, >>> sip:someapplication@P@). >>> To ensure that P1 would use TLS to P2 (as they want), I'd just >>> put >>> a "User TLS" checkbox. >>> >>> That seems to me to be a lot less broken that trying to squeeze >>> it >>> into third-party REGISTER. >> >> This is getting closer to the P1->P2 hop, but its a bit of a herring >> that >> you've separated 1st and 3rd party registration. I could have >> something@P1 >> in both to: and from: and still point it at application@P2. >> >> I understand where you are going with "make that a checkbox on >> somebody's GUI" and >> that's exactly what I'm saying isn't good enough. The preference >> needs to be reflected in the URI. >> >> For the registration case, binding things between P1 and P2, let me >> try yet another way to say this. >> >> It's in the field. >> People are USING it. >> We are trying to say "Don't do that" without giving an alternative >> that works in that scenario. >> We will be ignored unless we can present a clear and compelling >> reason why someone >> is putting life or limb at risk to do this (and I suspect we'll be >> ignored even then). >> >> I'm not sure I can make any such argument around just this transport >> parameter. If we're >> going to allow someone to say "udp" or "tcp" in this case, >> its rather >> pointless to not let them >> say tls (with the appropriate caveats around not having the >> anchor in >> DNS to verify who >> you're talking to). >> >> I _can_ make an argument around the notion of putting state in that >> doesn't point directly to you, >> but that goes way way beyond just the transport parameter, and if >> we're going to go there, we >> need to start an entirely different conversation that will take the >> transport parameter completely >> off the table for _any_ transport. >> >> RjS >> >>> >>> >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: Monday, June 04, 2007 14:55 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Dean Willis; SIP IETF >>>> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >>>> thoughts on transport=tls? >>>> >>>> Ok - we're closer, but not quite together yet. >>>> >>>> Lets start with a different message from the UAC where the >>>> RURI is simply >>>> sip:something@P1 >>>> >>>> The authority for something@P1 (the person that might send a >>>> register request with that in the To: header) wants >> requests to go to >>>> sip:someapplication@P2 >>>> and they want it to go over TLS. What they'd _like_ to do is >>>> send a register request with a contact that says to use TLS, >>>> or at most, send a single URI to the operators of P1 that >>>> describes where to send requests that show up for something@P1. >>>> >>>> What tools do we give them to make the statement they want to make? >>>> >>>> RjS >>>> >>>> >>>> >>>> On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: >>>> >>>>>> This is exactly where we are disagreeing. >>>>>> >>>>>> How do you _tell_ P1 that you want to reach P2 using TLS >>>> in the first >>>>>> place. >>>>>> As I said elsewhere in the thread, I don't think leaving this >>>>>> unspecified ("you just do this with the configuration of the >>>>>> proxy") is the right answer. If you have DNS, you tell >> P1 about P2 >>>>>> using DNS. If you don't have DNS, using the transport >> parameter in >>>>>> the URI you hand it seems pretty natural. That's how >>>> you're going to >>>>>> tell it to use udp or tcp... >>>>> >>>>> >>>>> I think I finally understand what you are saying... >>>>> >>>>> Say UAC sends request to Request-URI uas@p2;transport=tls. >>>>> >>>>> The transport parameter indicates that the resource in the >>>> request URI >>>>> (uas@p2) is the one that needs to be contacted with TLS. >>>> Therefore, it >>>>> would be the P1 -> P2 link that would use TLS in this case >>>> (since P2 >>>>> owns that domain). And P2 could use whatever it wants for P2 -> >>>>> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy >>>>> between P1 and P2) could use whatever they want. >>>>> >>>>> The use case would be where the UAC "trust" it own domain >>>> and does not >>>>> feel it necessary to use TLS, and/or the UAC "trusts" the target >>>>> domain for being responsible of that happens inside the >>>> target domain. >>>>> And finally, the UAC does not really care if there are >>>> other types of >>>>> proxies in the middle (not responsible for a specific >> domain), that >>>>> may not use TLS. >>>>> >>>>> While I understand that this is in theory something that could be >>>>> solvable, I'm not sure why it is such an interesting case. >>>> Seems to me >>>>> it is only of value if the only "vulnerable" hop is the >> one between >>>>> the source and target domains, and if there are no other proxies >>>>> between them (e.g., no "Service provider"). >>>>> >>>>> In fact, it pretty much describes to me why you should be >>>> using SIPS >>>>> in the first place. >>>>> >>>>> Do we *really* want to reintroduce transport=tls for this case? >>>>> >>>>> Side note: I just want to point out that RFC 2543 did NOT >> allow the >>>>> presence of the transport parameter at all in a Request-URI >>>> and 2543 >>>>> servers would ignore it or remove it. >>>> >>>> >> >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 09:54:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZTz-0003cW-Op; Tue, 05 Jun 2007 09:53:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvZTx-0003Ya-Uy for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 09:53:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZTx-0003YS-L9 for sip@ietf.org; Tue, 05 Jun 2007 09:53:57 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZTw-0000Ce-DJ for sip@ietf.org; Tue, 05 Jun 2007 09:53:57 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HvZUJ-0000mk-0s; Tue, 05 Jun 2007 06:54:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Server srv records? Date: Tue, 5 Jun 2007 06:53:53 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C31709F@sea02-mxc01.citel.com> In-Reply-To: <18021.26876.281550.48449@tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Server srv records? thread-index: Acend9uXGN7OhSz2QTmIuWqFHIaOHAAAO2eQ References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com><1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com><8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com><18020.29409.16674.687762@tutpro.com><2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com><18020.30897.464008.26643@tutpro.com><839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com><18020.32366.567052.462492@tutpro.com><009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> From: "Steve Langstaff" To: "Juha Heinanen" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > From: Juha Heinanen [mailto:jh@tutpro.com]=20 >=20 > Jeroen van Bemmel writes: >=20 > > For clients one would distribute=20 > "client-interface.example.com" as the > outbound proxy FQDN=20 > to use, and upstream proxies would be given >=20 > "server-interface.example.com" (by using that as domain in AORs). >=20 > i don't get this. the domain of SIP UAs' SIP uris is=20 > example.com for which the queries are done, not something=20 > else. clients would need to prefix that with _sip-client and=20 > servers with _sip-server. currently there is no standard for that. When you say "clients" and "servers", do you mean UACs and UASs, or some other use of the words? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 10:38:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaAX-0004lF-EC; Tue, 05 Jun 2007 10:37:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvaAW-0004kW-A3 for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 10:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaAV-0004jH-Tt for sip@ietf.org; Tue, 05 Jun 2007 10:37:55 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvaAU-0007wT-Hu for sip@ietf.org; Tue, 05 Jun 2007 10:37:55 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id DE4661EC68F; Tue, 5 Jun 2007 17:37:53 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzkaV1oi2Z0k; Tue, 5 Jun 2007 17:37:50 +0300 (EEST) Received: from taimen (primer151.gprs.dnafinland.fi [62.78.125.151]) by tutpro.com (Postfix) with ESMTP; Tue, 5 Jun 2007 17:37:50 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 08E76AC145; Tue, 5 Jun 2007 17:37:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18021.30009.696278.607996@tutpro.com> Date: Tue, 5 Jun 2007 17:37:45 +0300 To: "Steve Langstaff" Subject: RE: [Sip] Server srv records? In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C31709F@sea02-mxc01.citel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <0D4E483A0E6E0A46861409E5D6C2011C31709F@sea02-mxc01.citel.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Steve Langstaff writes: > > i don't get this. the domain of SIP UAs' SIP uris is > > example.com for which the queries are done, not something > > else. clients would need to prefix that with _sip-client and > > servers with _sip-server. currently there is no standard for that. > > When you say "clients" and "servers", do you mean UACs and UASs, or some > other use of the words? client is sip ua and server is a sip proxy. see sections 14.3 and 14.4 of rfc 3920. -- 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 sip-bounces@ietf.org Tue Jun 05 10:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaIZ-0001DF-80; Tue, 05 Jun 2007 10:46:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvaIX-0001Cu-N7 for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 10:46:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvaIX-0001Cl-DA for sip@ietf.org; Tue, 05 Jun 2007 10:46:13 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvaIV-0001Wb-HK for sip@ietf.org; Tue, 05 Jun 2007 10:46:13 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 05 Jun 2007 07:46:09 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208"; a="14292599:sNHT136154450" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:46:06 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Tue, 5 Jun 2007 15:46:04 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Thread-Index: AceneFPyCtmxJM4MQjKLhpfsWULacwABP/0w References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> From: "Gilad Shaham" To: "Robert Sparks" , "Francois Audet" X-OriginalArrivalTime: 05 Jun 2007 14:46:06.0691 (UTC) FILETIME=[3F887B30:01C7A780] X-Spam-Score: 0.0 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I can add even more complications (even though it seems complicated enough, but what the heck). What if we want to specify the encryption level (e.g. 40 bits or 128 bits)? What if we want to specify IPSec? It seems to me that transport=3Dtls in the request URI causes a lot of historical issues. Maybe there is a need for a feature tag/header that defines the allowed secure methods for examples: Unencrypted, tls, ipsec The proxy would then be free to do whatever lookup method it wants (via DNS, according to outbound or any policy) and it will forward the request only if there is an option within one of the possible values it received on the request. Just a thought, I hope it helps. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Tuesday, June 05, 2007 4:49 PM > To: Francois Audet > Cc: SIP IETF; Dean Willis > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts > ontransport=3Dtls? >=20 >=20 > On Jun 4, 2007, at 7:14 PM, Francois Audet wrote: >=20 > > Hi Robert, > > > > I understand what you are saying. And you are right: my point about > > Third > > party registration was a red herring: it's really the Contact being > > different than the source of the REGISTER that is a problem). > > > > But frankly, the transport parameter in general IMHO is a problem. The > > fact that SIP isn't layered properly on top of TCP (or UDP) is the > > issue frankly. > > > > In a world where there are no NATs, no FW and every Joe has it's own > > user certificate, we could make the transport parameter work. > > > > If we re-introduce transport=3Dtls, then we'll have to explain when = it > > will > > work. We will have to write big caveats that it won't work unless you > > have no NAT, no Firewall, and you are using Mutual-TLS with User > > certificates for the UAs. In general, it won't work. >=20 > So I understand your position on how this affects devices we expect to > be behind transport-destroying elements and that we don't expect to > generally have certificates. >=20 > What about the proxy->proxy (or some stable network server) hop, where > we expect there _isn't_ a transport-destroying intermediary (hah) and > that > we expect they _do_ have certificates? This is the case where I think we > have a real constituency (with real applications) that we're harming. >=20 > Consider the routing decision that P1 needs to make. The tools we have > allow P1 to choose among the protocols it knows how to use by > administrative > configuration. They let P2 express policy about which protocols P1 > should use > (through DNS). What they don't do is let P1 choose between protocols > based > on a user's (or application's) input. >=20 > We've got this concept of a location service that you access using > REGISTER. > The spec talks about running it separately from a proxy - so consider > the case > where a proxy either does query REGISTERs or sends a request to a > redirect > server to figure out where it's supposed to go. What it gets back is > URIs in > Contact header fields. How can the location service tell the proxy > that's asking > for a routing decision that "for this input URI, goto this output URI > and use TLS"? >=20 > RjS >=20 > > > > In my mind, we would be doing a disservice to the industry by writing > > protocol to do something that almost never works. The "But I can do it > > today in the field (but just for TCP)" doesn't hold water, because TLS > > is not TCP. > > > > Furthermore, this "transport=3Dtls" stuff is not documented anywhere in > > any RFC. So we would be writing from scratch broken procedures to > > "document" broken practices in the field. Seems insane to me. > > > > The clear and compelling reason to not use "transport=3Dtls" is that it > > won't generally work, except for very contrived scenarios. > > > > PS: "Transport=3Dtls" was "deprecated" in RFC 3261, but it didn't exist > > either in its predecessor RFC 2543. It was only defined in the > > the draft-ietf-sip-rfc2543bis-00. So the implementations that use > > it today do not conform to any RCF, obsolete or otherwise. > > > > > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >> Sent: Monday, June 04, 2007 15:52 > >> To: Audet, Francois (SC100:3055) > >> Cc: Dean Willis; SIP IETF > >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > >> thoughts on transport=3Dtls? > >> > >> > >> On Jun 4, 2007, at 5:34 PM, Francois Audet wrote: > >> > >>> Ok, so it has nothing to do with Request-URI then (which is what I > >>> tought we were talking about). > >> > >> Well, we're still not connecting quite yet. > >> > >> It has _EVERYTHING_ to do with Request-URI. > >> > >> It is coincidence that I'm populating what the RURI will be > >> after retargetting with a REGISTER. It could have been any > >> other mechanism. The important part is what comes out into > >> the Request-URI of the P1->P2 link. > >> > >>> > >>> I don't believe that using transport=3Dtls in Contact for > >> Registration > >>> will generally work. > >> (as you read my inline responses below, ask yourself what > >> =3Dtls has to do with what you wrote - I think I can substitute =3Dtcp, > >> which we _do_ allow, and everything but the comments about > >> mutual or server auth still stand) > >>> > >>> There are 2 cases: > >>> > >>> From =3D=3D To in REGISTER (First Party Registration) > >>> ------------------------------------------------- > >>> > >>> In this case, if we use SIP-Outbound, we DO already > >>> have a solution. > >> Surely you're not suggesting proxies do outbound between them. > >> You're latching onto the endpoint case. I'm talking about a > >> server to server case. > >> > >>> > >>> With SIP-outbound, the connection used by the registration > >>> process is kept alive and reused for both incoming and > >>> outgoing requests. > >>> > >>> It has the advantage that it will support environments > >>> where server-provided certificates are used since > >>> the TLS connection will only be establishable by the > >>> client. > >>> > >>> A a bonus, SIP-outbound also solves NAT and FW traversal, if > >>> there happens to be one. > >>> > >>> Their proposed solution of using a transport parameter > >>> will not work for server-provided certificates as the > >>> server will not be able to establish a connection with > >>> the client. Since server-provided certificates is by far > >>> the most commone deployment scenario (as opposed to > >>> Mutual TLS) for UAs, this is a big problem. > >>> > >>> Their proposed solution wouldn't work either if there is > >>> a NAT or Firewall. Again, big problem. > >>> > >>> Their proposed solution would therefore ONLY be > >>> suitable for environments where Mutual TLS is used, and > >>> where there are no NATs or Firewall. > >>> > >>> The SIP-outbound mechanism also works with Mutual TLS. > >>> > >>> Therefore, for this case, I do not believe that their > >>> mechanism is general enough to be standardized. > >>> > >>> This is described at lenght in the draft. > >>> > >>> > >>> From !=3D To in REGISTER (Third Party Registration) > >>> ------------------------------------------------- > >>> > >>> Third party registration is problematic for both their > >>> proposed solution, as well as for SIP-outbound. > >>> > >>> For SIP-outbound, well, it plainly doesn't work. > >>> > >>> For their proposed solution, it is a security problem > >>> since it effectively allows a non-secure user (the "authority" > >>> as you call it), to request that session be delivered securily. > >>> Dr, Evil person could hijack the "authority" role and redirects > >>> all sessions to wherever it wants, and the sessions would be > >>> "secured" with Dr. Evil. > >>> > >>> Furthermore, their proposed solution would not work in this > >>> case either with server-provided certificates, or if there > >>> is a NAT or Firewall. Again, big problem. > >>> > >>> To me, it means that Third Party Registration is just plain > >>> bad in a secure environment. > >>> > >>> In fact, I don't like the idea of allowing third party > >>> registration to allow a UAC with AOR in p1 domain to > >>> register a contact in a different domain (p2 in this case). > >>> That contact is effectively an AOR. > >>> > >>> How would I solve the problem? > >>> > >>> I would expect the other UA (sip:someapplication@P2) to do it's > >>> own registration in it's own domain P2, according to the rules > >>> of it's > >>> own domain. If P2 is using server-provided certificates, it > >>> would > >>> work (with Outbound). If a NAT is present, it would works as > >>> well. > >>> > >>> Then, I would allow user "something@P1" to log in securily > >>> on the Proxy (with HTTPS for example), and request routing to > >>> be done to another address (in this case, > >>> sip:someapplication@P@). > >>> To ensure that P1 would use TLS to P2 (as they want), I'd just > >>> put > >>> a "User TLS" checkbox. > >>> > >>> That seems to me to be a lot less broken that trying to squeeze > >>> it > >>> into third-party REGISTER. > >> > >> This is getting closer to the P1->P2 hop, but its a bit of a herring > >> that > >> you've separated 1st and 3rd party registration. I could have > >> something@P1 > >> in both to: and from: and still point it at application@P2. > >> > >> I understand where you are going with "make that a checkbox on > >> somebody's GUI" and > >> that's exactly what I'm saying isn't good enough. The preference > >> needs to be reflected in the URI. > >> > >> For the registration case, binding things between P1 and P2, let me > >> try yet another way to say this. > >> > >> It's in the field. > >> People are USING it. > >> We are trying to say "Don't do that" without giving an alternative > >> that works in that scenario. > >> We will be ignored unless we can present a clear and compelling > >> reason why someone > >> is putting life or limb at risk to do this (and I suspect we'll be > >> ignored even then). > >> > >> I'm not sure I can make any such argument around just this transport > >> parameter. If we're > >> going to allow someone to say "udp" or "tcp" in this case, > >> its rather > >> pointless to not let them > >> say tls (with the appropriate caveats around not having the > >> anchor in > >> DNS to verify who > >> you're talking to). > >> > >> I _can_ make an argument around the notion of putting state in that > >> doesn't point directly to you, > >> but that goes way way beyond just the transport parameter, and if > >> we're going to go there, we > >> need to start an entirely different conversation that will take the > >> transport parameter completely > >> off the table for _any_ transport. > >> > >> RjS > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] > >>>> Sent: Monday, June 04, 2007 14:55 > >>>> To: Audet, Francois (SC100:3055) > >>>> Cc: Dean Willis; SIP IETF > >>>> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > >>>> thoughts on transport=3Dtls? > >>>> > >>>> Ok - we're closer, but not quite together yet. > >>>> > >>>> Lets start with a different message from the UAC where the > >>>> RURI is simply > >>>> sip:something@P1 > >>>> > >>>> The authority for something@P1 (the person that might send a > >>>> register request with that in the To: header) wants > >> requests to go to > >>>> sip:someapplication@P2 > >>>> and they want it to go over TLS. What they'd _like_ to do is > >>>> send a register request with a contact that says to use TLS, > >>>> or at most, send a single URI to the operators of P1 that > >>>> describes where to send requests that show up for something@P1. > >>>> > >>>> What tools do we give them to make the statement they want to make? > >>>> > >>>> RjS > >>>> > >>>> > >>>> > >>>> On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: > >>>> > >>>>>> This is exactly where we are disagreeing. > >>>>>> > >>>>>> How do you _tell_ P1 that you want to reach P2 using TLS > >>>> in the first > >>>>>> place. > >>>>>> As I said elsewhere in the thread, I don't think leaving this > >>>>>> unspecified ("you just do this with the configuration of the > >>>>>> proxy") is the right answer. If you have DNS, you tell > >> P1 about P2 > >>>>>> using DNS. If you don't have DNS, using the transport > >> parameter in > >>>>>> the URI you hand it seems pretty natural. That's how > >>>> you're going to > >>>>>> tell it to use udp or tcp... > >>>>> > >>>>> > >>>>> I think I finally understand what you are saying... > >>>>> > >>>>> Say UAC sends request to Request-URI uas@p2;transport=3Dtls. > >>>>> > >>>>> The transport parameter indicates that the resource in the > >>>> request URI > >>>>> (uas@p2) is the one that needs to be contacted with TLS. > >>>> Therefore, it > >>>>> would be the P1 -> P2 link that would use TLS in this case > >>>> (since P2 > >>>>> owns that domain). And P2 could use whatever it wants for P2 -> > >>>>> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy > >>>>> between P1 and P2) could use whatever they want. > >>>>> > >>>>> The use case would be where the UAC "trust" it own domain > >>>> and does not > >>>>> feel it necessary to use TLS, and/or the UAC "trusts" the target > >>>>> domain for being responsible of that happens inside the > >>>> target domain. > >>>>> And finally, the UAC does not really care if there are > >>>> other types of > >>>>> proxies in the middle (not responsible for a specific > >> domain), that > >>>>> may not use TLS. > >>>>> > >>>>> While I understand that this is in theory something that could be > >>>>> solvable, I'm not sure why it is such an interesting case. > >>>> Seems to me > >>>>> it is only of value if the only "vulnerable" hop is the > >> one between > >>>>> the source and target domains, and if there are no other proxies > >>>>> between them (e.g., no "Service provider"). > >>>>> > >>>>> In fact, it pretty much describes to me why you should be > >>>> using SIPS > >>>>> in the first place. > >>>>> > >>>>> Do we *really* want to reintroduce transport=3Dtls for this = case? > >>>>> > >>>>> Side note: I just want to point out that RFC 2543 did NOT > >> allow the > >>>>> presence of the transport parameter at all in a Request-URI > >>>> and 2543 > >>>>> servers would ignore it or remove it. > >>>> > >>>> > >> > >> >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 12:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvc3m-00013G-SE; Tue, 05 Jun 2007 12:39:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvc3l-00013B-Jf for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 12:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvc3l-000133-AB for sip@ietf.org; Tue, 05 Jun 2007 12:39:05 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvc3j-0003kK-TU for sip@ietf.org; Tue, 05 Jun 2007 12:39:05 -0400 Received: (qmail 21797 invoked by uid 0); 5 Jun 2007 16:39:02 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jun 2007 16:39:02 -0000 Message-ID: <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Juha Heinanen" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com><1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com><8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com><18020.29409.16674.687762@tutpro.com><2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com><18020.30897.464008.26643@tutpro.com><839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com><18020.32366.567052.462492@tutpro.com><009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> Subject: Re: [Sip] Server srv records? Date: Tue, 5 Jun 2007 18:37:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha, In that case "example.com" would be the server interface (and configured as such in DNS SRV). Clients would be given "x.example.com", where x can be anything you like (or "x.y.z", as long as you control the y.z domain in DNS SRV) It's not exactly the same as for XMPP, where you say each element uses a prefix based on its role. But it would have a similar effect of separating preferred protocols (and other SRV attributes) per client (registration/outbound) versus other elements (e.g. proxies) Regards, Jeroen Juha Heinanen wrote: > Jeroen van Bemmel writes: > >> For clients one would distribute "client-interface.example.com" as >> the outbound proxy FQDN to use, and upstream proxies would be given >> "server-interface.example.com" (by using that as domain in AORs). > > i don't get this. the domain of SIP UAs' SIP uris is example.com for > which the queries are done, not something else. clients would need to > prefix that with _sip-client and servers with _sip-server. currently > there is no standard for 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 sip-bounces@ietf.org Tue Jun 05 12:52:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcH7-0000Fz-P5; Tue, 05 Jun 2007 12:52:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvcH6-0000Fu-Hq for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 12:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcH6-0000Fm-8L for sip@ietf.org; Tue, 05 Jun 2007 12:52:52 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcH3-0007c6-Rf for sip@ietf.org; Tue, 05 Jun 2007 12:52:52 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id E3F361EC68F; Tue, 5 Jun 2007 19:52:48 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSGUBFFmincL; Tue, 5 Jun 2007 19:52:46 +0300 (EEST) Received: from taimen (primer151.gprs.dnafinland.fi [62.78.125.151]) by tutpro.com (Postfix) with ESMTP; Tue, 5 Jun 2007 19:52:46 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 4299BAC17D; Tue, 5 Jun 2007 19:52:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18021.38106.242640.743299@tutpro.com> Date: Tue, 5 Jun 2007 19:52:42 +0300 To: "Jeroen van Bemmel" Subject: Re: [Sip] Server srv records? In-Reply-To: <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Bob Penfield , SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel writes: > In that case "example.com" would be the server interface (and configured as > such in DNS SRV). Clients would be given "x.example.com", where x can be > anything you like (or "x.y.z", as long as you control the y.z domain in DNS > SRV). jeroen, clients are existing standard sip clients that not given anything else but aor, username and password. then they automatically make srv query on example.com, not on x.example.com. of course by manual configuration of outbound proxy you can accomplish whatever, but that is not what users want. they want as little configuration as possible and configuring outbound proxy manually is out of question. -- 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 sip-bounces@ietf.org Tue Jun 05 14:28:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvdlh-0006GI-S4; Tue, 05 Jun 2007 14:28:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvdlf-0006GD-RL for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 14:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvdlf-0006G5-Hp for sip@ietf.org; Tue, 05 Jun 2007 14:28:31 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvdlf-000606-8z for sip@ietf.org; Tue, 05 Jun 2007 14:28:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l55IRB820717; Tue, 5 Jun 2007 18:27:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Tue, 5 Jun 2007 13:28:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C0C5F0@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: AceneEajO5aNTDaeTB+VIJWyRKubswAHT91Q References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com> <1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com> <46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Robert Sparks" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Robert. See below. Make sure you reach the end before replying back. > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: Tuesday, June 05, 2007 06:49 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? > > What about the proxy->proxy (or some stable network server)=20 > hop, where we expect there _isn't_ a transport-destroying=20 > intermediary (hah) and that we expect they _do_ have=20 > certificates? This is the case where I think we have a real=20 > constituency (with real applications) that we're harming. >=20 > Consider the routing decision that P1 needs to make. The=20 > tools we have allow P1 to choose among the protocols it knows=20 > how to use by administrative configuration. They let P2=20 > express policy about which protocols P1 should use (through=20 > DNS). What they don't do is let P1 choose between protocols=20 > based on a user's (or application's) input. Hi Robert, yes, I think it is a good summary. I'm not sure that we are "harming" anything by not having = transport=3Dtls because P1 can use static configuration or DNS to determine the transport to use between P1 and P2. The only thing that not having a transport=3Dtls parameter implies is that P1 (as you put it) will not be able to determine that TLS should be used between P1 and P2 based on User (UAC) input (on that hop only). Transport=3Dtls would allow the user to insist on the transport being tls for the last hop before the target domain (but says nothing about other hops). I'm still not convinced that this particular behavior is required or even=20 desired. Remember that the UAC does have the means to enforce TLS accross ALL the hops using SIPS.=20 Nevertheless, if people want to re-instate transport=3Dtls, we can do it. It would have to include lots of text to explain the limitations, but it can certainly be done. > We've got this concept of a location service that you access=20 > using REGISTER. > The spec talks about running it separately from a proxy - so=20 > consider the case where a proxy either does query REGISTERs=20 > or sends a request to a redirect server to figure out where=20 > it's supposed to go. What it gets back is URIs in Contact=20 > header fields. How can the location service tell the proxy=20 > that's asking for a routing decision that "for this input=20 > URI, goto this output URI and use TLS"? Yes, that is certainly a more concrete use case. Both for=20 the location service you mention, or for redirect servers in general (when used for routing). This may be the main technical reason for re-instating transport=3Dtls. I'd be willing to go along with that. There is also another reason, this time practical, for re-instating transport=3Dtls. It is the fact that most implementations that support TLS today seem to use it. I've attempted to mitigate this problem in the current draft by writing up rules on how to deal with = transport=3Dtls in a backward compatible way, but I'm not convinced that it's enough. Perhaps formally recognizing transport=3Dtls, and describing it's limitations (e.g., it doesn't solve NAT/FW, doesn't work with server-provided certs, etc.). Let's wait to see if anybody else chimes in on the idea of re-instating transport=3Dtls. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 15:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveIJ-0002rc-HW; Tue, 05 Jun 2007 15:02:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HveII-0002rI-8i for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveIH-0002r8-VE for sip@ietf.org; Tue, 05 Jun 2007 15:02:13 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HveIG-0005la-Gy for sip@ietf.org; Tue, 05 Jun 2007 15:02:13 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l55J2B7w016388 for ; Tue, 5 Jun 2007 13:02:11 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 5 Jun 2007 13:02:11 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Jun 2007 13:02:11 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C617EC96@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated SIP Certificate Authentication requirements draft Thread-Index: AcenpAW46ZvdU47TTXWDYxcWOhXGCA== From: "Steve Dotson" To: "IETF SIP List" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [Sip] Updated SIP Certificate Authentication requirements draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800056384==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1800056384== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A7A4.058D47AB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A7A4.058D47AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to call your attention to an updated SIP Certificate Authentication requirements draft, which is the result of additional feedback. More feedback/comments appreciated. =20 A New Internet-Draft is available from the on-line Internet-Drafts directories. =20 =20 Title : Certificate Authentication in SIP Author(s) : S. Dotson Filename : draft-dotson-sip-certificate-auth-03.txt Pages : 14 Date : 2007-6-1 =20 This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). This document is being presented with the intention of providing clear requirements to any potential solutions specifying certificate authentication within SIP networks. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt =20 =20 Thanks, =20 Steve. =20 ------_=_NextPart_001_01C7A7A4.058D47AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I = would like to call=20 your attention to an updated SIP Certificate Authentication requirements = draft,=20 which is the result of additional feedback. More feedback/comments=20 appreciated.
 

A New Internet-Draft is = available=20 from the on-line Internet-Drafts directories.

 

 

           =20 Title           &nbs= p;     =20 : Certificate Authentication in SIP

           =20 Author(s)          =20 : S. Dotson

           =20 Filename          =20 : draft-dotson-sip-certificate-auth-03.txt

           =20 Pages           &nbs= p;  =20 : 14

           =20 Date           &nbs= p;    =20 : 2007-6-1

           =20

This document defines = requirements=20 for adding certificate

   authentication to the = Session=20 Initiation Protocol (SIP). =20 This

   document is being = presented with=20 the intention of providing clear

   requirements to any = potential=20 solutions specifying certificate

   authentication within = SIP=20 networks.  Supporting=20 certificate

   authentication in SIP = would=20 provide strong authentication and

   increase the types of = possible=20 deployment scenarios.

 

A URL for this = Internet-Draft=20 is:

http://www.ietf.org/internet-drafts/draft-dotson-sip-certifi= cate-auth-03.txt

 

 

Thanks,

 

Steve.

 

------_=_NextPart_001_01C7A7A4.058D47AB-- --===============1800056384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1800056384==-- From sip-bounces@ietf.org Tue Jun 05 15:13:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveTD-00035L-S0; Tue, 05 Jun 2007 15:13:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HveTC-0002yv-C3 for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveTC-0002xz-1p for sip@ietf.org; Tue, 05 Jun 2007 15:13:30 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HveTB-0000Ei-IQ for sip@ietf.org; Tue, 05 Jun 2007 15:13:30 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l55JDSrh020730; Tue, 5 Jun 2007 13:13:28 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 5 Jun 2007 13:13:28 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Date: Tue, 5 Jun 2007 13:13:28 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> In-Reply-To: <20070310210143.466231CC77@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Thread-Index: AcdjV5vAXxGSnwWIRQ2Zy3wLPXZBURETaYiQ References: <20070310210143.466231CC77@delta.rtfm.com> From: "Steve Dotson" To: "EKR" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric, thank you for the comments and sorry for the slow response. As you stated this was a first draft solution based on draft-dotson-sip-certificate-auth. We have since updated the requirements draft to -03 which can be found at http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt. The reasoning behind choosing a challenge/response paradigm is that is the current model used in SIP, and allows a registrar to control when and if to authenticate UAs. S/MIME could be a potential mechanism, as could Identity or AIB in theory. At a high-level we weren't as concerned with the actual mechanism as the signaling and messaging, since the signing of some set of data seems to be similar across all the current solutions. What we seem to be missing is the signaling and messaging to use certificates for authenticating to a registrar/network or another UA. Without challenge/response, the UA would always need to do cryptographic processing and messages are larger, whether or not the other end is requiring authentication. For UA to UA authentication, the issue is even more of a concern, as we don't want UAs assuming authentication of every dialog request. Is it a fair statement that S/MIME/AIB/Identity all use similar cryptographic tools but vary in the specific data from the dialog chosen to sign?=20 Is there any preference to which "mechanism" is used for the solution? Do all the solutions have issues with middleboxes? Thanks. Steve. =20 -----Original Message----- From: EKR [mailto:ekr@networkresonance.com]=20 Sent: Saturday, March 10, 2007 2:02 PM To: sip@ietf.org Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 $Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1 2007/03/10 21:13:10 ekr Exp $ The native SIP authentication scheme is Digest authentication. This draft and its companion draft-dotson-sip-certificate-auth argue that it is desirable to have an authentication scheme based on public key certificates that can span multiple hops (TLS client auth lets you authenticate to the first hop proxy). To some extent, SIP already has such a scheme: messages can be S/MIME signed. As I understand it, the primary deficiencies claimed for S/MIME are: - There is no way for the server to indicate he wants you to S/MIME sign. - There is no built-in defense against replay attacks. In order to correct this situation, this draft proposes an extension to HTTP Digest to add a signature mode. I'm not sure how important this problem actually is, but I'm skeptical that this draft is the best way to go about it. It seems to me that this proposal confuses two issues: 1. The formatting of the signature over the data. 2. How the server indicates that it wants a signature. This proposal addresses both, but its solution to (1) is clumsy and replicates functionality we already have, namely S/MIME. It's fine to define a new form of authentication challenge that says "please sign with your S/MIME cert" and even have it include a nonce, but there's no need to model the response on Digest auth. You can simply include the challenge in the material you sign over. Incidentally, I've heard people argue that it would be nice to have a generic solution for both HTTP and SIP. This problem has already been attacked for HTTP (though with minimal adoption). See S-HTTP (RFC 2660). -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 15:57:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf9M-0003OZ-8Q; Tue, 05 Jun 2007 15:57:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvf9K-0003OS-SX for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 15:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf9K-0003OK-J3 for sip@ietf.org; Tue, 05 Jun 2007 15:57:02 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvf9J-0005E1-6P for sip@ietf.org; Tue, 05 Jun 2007 15:57:02 -0400 Received: (qmail 31470 invoked by uid 0); 5 Jun 2007 19:56:31 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jun 2007 19:56:31 -0000 Message-ID: <08f001c7a7ab$62c348c0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , "Robert Sparks" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10C0C5F0@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Tue, 5 Jun 2007 21:54:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, Robert, see below Regards, Jeroen >> We've got this concept of a location service that you access >> using REGISTER. >> The spec talks about running it separately from a proxy - so >> consider the case where a proxy either does query REGISTERs >> or sends a request to a redirect server to figure out where >> it's supposed to go. What it gets back is URIs in Contact >> header fields. How can the location service tell the proxy >> that's asking for a routing decision that "for this input >> URI, goto this output URI and use TLS"? > > Yes, that is certainly a more concrete use case. Both for > the location service you mention, or for redirect servers in > general (when used for routing). > > This may be the main technical reason for re-instating transport=tls. > I'd be willing to go along with that. To me, the way it should work is that TLS would be used if the returned URI was a "sips:" URI, or if the returned URI was a "sip:" URI and the proxy decides to upgrade it to "sips:" (i.e. due to local policy). I don't see the need for transport=tls in this case Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 16:57:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvg5l-0004df-Uh; Tue, 05 Jun 2007 16:57:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvg5k-0004dZ-Lx for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 16:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvg5k-0004dR-CX for sip@ietf.org; Tue, 05 Jun 2007 16:57:24 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvg5i-00030F-Dw for sip@ietf.org; Tue, 05 Jun 2007 16:57:23 -0400 Received: (qmail 21738 invoked by uid 0); 5 Jun 2007 20:57:18 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 5 Jun 2007 20:57:18 -0000 Message-ID: <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> Date: Tue, 5 Jun 2007 22:55:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois, Refer to RFC3261 16.5: if a proxy is not responsible for the request URI it MUST NOT recurse on 302 416 does not have the right semantics (since the endpoint may in fact support sips, proxies currently should never generate this response) and RFC3261 section 16.7 step 4 says that a proxy responsible for the URI should recurse on it (should only happen in call forwarding scenarios, but still) Lots of other error responses would prevent automatic recursion, but that does not make them any more suitable than 403 (which is not suitable either, IMHO) If you really want to be on the safe side, a new 4xx response code would be best Regards, Jeroen Francois Audet wrote: > Actually, 416 would achieve what you want. > 302 would not be backward compatible because some proxy somewhere > could recurse on it, resulting in a downgrade. > > If people prefer a 416, I can put that. > > I do personaly prefer the 403, because I'd like to avoid any thing > that would cause a proxy to "automatically" recurse, thereby resulting > in a downgrade. > > ________________________________ > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Monday, June 04, 2007 16:20 > To: sip@ietf.org > Cc: Audet, Francois (SC100:3055) > Subject: draft-ietf-sip-sips-04: 403 instead of last hop > exception > > > In section 4.2 > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt > proposes that a proxy should send 403 rather than apply the last hop > exception. > > Instead, I would propose that it would send a 302 with either > the registered Contact or the received request URI with a "sip:" > scheme. 403 would be confusing, because the caller cannot distinguish > between this case and the callee refusing his call. Perhaps a new > response code (4xx Unsecure transport not allowed) would be better. > > Perhaps a caller preference should be defined to request such > behavior, similar to "fork" and "no-fork" (RFC3841). Say "no-sips-sip" > > Regards, > Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 19:17:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviGz-0007eq-QQ; Tue, 05 Jun 2007 19:17:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HviGz-0007el-1e for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 19:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviGy-0007ed-NA for sip@ietf.org; Tue, 05 Jun 2007 19:17:08 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HviGx-0007ba-Im for sip@ietf.org; Tue, 05 Jun 2007 19:17:08 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2007 16:17:07 -0700 X-IronPort-AV: i="4.16,386,1175497200"; d="scan'208"; a="377415545:sNHT86442510" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l55NH74u016592; Tue, 5 Jun 2007 16:17:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l55NH022003753; Tue, 5 Jun 2007 23:17:06 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 19:17:01 -0400 Received: from [10.86.242.49] ([10.86.242.49]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 19:17:00 -0400 Message-ID: <4665EEED.7000708@cisco.com> Date: Tue, 05 Jun 2007 19:17:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gilad Shaham Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> <0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2007 23:17:00.0427 (UTC) FILETIME=[9E9565B0:01C7A7C7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=15924; t=1181085427; x=1181949427; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Ready=20for=20WGLC=20on=20SIPS=20draft?=20Any =20last=20thoughts=09ontransport=3Dtls? |Sender:=20; bh=yfTJMjCw3BpV1NN33P7TJcuzy2aW53HeeLjQPLczRtg=; b=uzg0ubs/TSkJUt4Y4Mu7RvffQOzwJT9/HG8XU/7aYcjW5MonIcfjIORbMx9sCUSXT6R8NTyB h1tQ0HzyHLPun418gMl8dN0sRi0Z0ubVPmao2tDxouUpOuKSjpJHiJio; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: SIP IETF , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jumping in. I just happened to pick Gilad's message to respond to. I've only been loosely following this discussion. But it seems to me that this transport=tls issue is a distraction from finishing the sips draft. Why does the sips draft have any responsibility for addressing this issue? I think it would be better to let the sips draft be finished and then move on to addressing all of the (many) important security issues that sips doesn't solve, as a separate effort. Paul Gilad Shaham wrote: > I can add even more complications (even though it seems complicated > enough, but what the heck). > What if we want to specify the encryption level (e.g. 40 bits or 128 > bits)? What if we want to specify IPSec? > > It seems to me that transport=tls in the request URI causes a lot of > historical issues. Maybe there is a need for a feature tag/header that > defines the allowed secure methods for examples: > Unencrypted, tls, ipsec > The proxy would then be free to do whatever lookup method it wants (via > DNS, according to outbound or any policy) and it will forward the > request only if there is an option within one of the possible values it > received on the request. > > Just a thought, I hope it helps. > > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: Tuesday, June 05, 2007 4:49 PM >> To: Francois Audet >> Cc: SIP IETF; Dean Willis >> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts >> ontransport=tls? >> >> >> On Jun 4, 2007, at 7:14 PM, Francois Audet wrote: >> >>> Hi Robert, >>> >>> I understand what you are saying. And you are right: my point about >>> Third >>> party registration was a red herring: it's really the Contact being >>> different than the source of the REGISTER that is a problem). >>> >>> But frankly, the transport parameter in general IMHO is a problem. > The >>> fact that SIP isn't layered properly on top of TCP (or UDP) is the >>> issue frankly. >>> >>> In a world where there are no NATs, no FW and every Joe has it's own >>> user certificate, we could make the transport parameter work. >>> >>> If we re-introduce transport=tls, then we'll have to explain when it >>> will >>> work. We will have to write big caveats that it won't work unless > you >>> have no NAT, no Firewall, and you are using Mutual-TLS with User >>> certificates for the UAs. In general, it won't work. >> So I understand your position on how this affects devices we expect to >> be behind transport-destroying elements and that we don't expect to >> generally have certificates. >> >> What about the proxy->proxy (or some stable network server) hop, where >> we expect there _isn't_ a transport-destroying intermediary (hah) and >> that >> we expect they _do_ have certificates? This is the case where I think > we >> have a real constituency (with real applications) that we're harming. >> >> Consider the routing decision that P1 needs to make. The tools we have >> allow P1 to choose among the protocols it knows how to use by >> administrative >> configuration. They let P2 express policy about which protocols P1 >> should use >> (through DNS). What they don't do is let P1 choose between protocols >> based >> on a user's (or application's) input. >> >> We've got this concept of a location service that you access using >> REGISTER. >> The spec talks about running it separately from a proxy - so consider >> the case >> where a proxy either does query REGISTERs or sends a request to a >> redirect >> server to figure out where it's supposed to go. What it gets back is >> URIs in >> Contact header fields. How can the location service tell the proxy >> that's asking >> for a routing decision that "for this input URI, goto this output URI >> and use TLS"? >> >> RjS >> >>> In my mind, we would be doing a disservice to the industry by > writing >>> protocol to do something that almost never works. The "But I can do > it >>> today in the field (but just for TCP)" doesn't hold water, because > TLS >>> is not TCP. >>> >>> Furthermore, this "transport=tls" stuff is not documented anywhere > in >>> any RFC. So we would be writing from scratch broken procedures to >>> "document" broken practices in the field. Seems insane to me. >>> >>> The clear and compelling reason to not use "transport=tls" is that > it >>> won't generally work, except for very contrived scenarios. >>> >>> PS: "Transport=tls" was "deprecated" in RFC 3261, but it didn't > exist >>> either in its predecessor RFC 2543. It was only defined in the >>> the draft-ietf-sip-rfc2543bis-00. So the implementations that > use >>> it today do not conform to any RCF, obsolete or otherwise. >>> >>> >>> >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: Monday, June 04, 2007 15:52 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Dean Willis; SIP IETF >>>> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >>>> thoughts on transport=tls? >>>> >>>> >>>> On Jun 4, 2007, at 5:34 PM, Francois Audet wrote: >>>> >>>>> Ok, so it has nothing to do with Request-URI then (which is what I >>>>> tought we were talking about). >>>> Well, we're still not connecting quite yet. >>>> >>>> It has _EVERYTHING_ to do with Request-URI. >>>> >>>> It is coincidence that I'm populating what the RURI will be >>>> after retargetting with a REGISTER. It could have been any >>>> other mechanism. The important part is what comes out into >>>> the Request-URI of the P1->P2 link. >>>> >>>>> I don't believe that using transport=tls in Contact for >>>> Registration >>>>> will generally work. >>>> (as you read my inline responses below, ask yourself what >>>> =tls has to do with what you wrote - I think I can substitute > =tcp, >>>> which we _do_ allow, and everything but the comments about >>>> mutual or server auth still stand) >>>>> There are 2 cases: >>>>> >>>>> From == To in REGISTER (First Party Registration) >>>>> ------------------------------------------------- >>>>> >>>>> In this case, if we use SIP-Outbound, we DO already >>>>> have a solution. >>>> Surely you're not suggesting proxies do outbound between them. >>>> You're latching onto the endpoint case. I'm talking about a >>>> server to server case. >>>> >>>>> With SIP-outbound, the connection used by the registration >>>>> process is kept alive and reused for both incoming and >>>>> outgoing requests. >>>>> >>>>> It has the advantage that it will support environments >>>>> where server-provided certificates are used since >>>>> the TLS connection will only be establishable by the >>>>> client. >>>>> >>>>> A a bonus, SIP-outbound also solves NAT and FW traversal, if >>>>> there happens to be one. >>>>> >>>>> Their proposed solution of using a transport parameter >>>>> will not work for server-provided certificates as the >>>>> server will not be able to establish a connection with >>>>> the client. Since server-provided certificates is by far >>>>> the most commone deployment scenario (as opposed to >>>>> Mutual TLS) for UAs, this is a big problem. >>>>> >>>>> Their proposed solution wouldn't work either if there is >>>>> a NAT or Firewall. Again, big problem. >>>>> >>>>> Their proposed solution would therefore ONLY be >>>>> suitable for environments where Mutual TLS is used, and >>>>> where there are no NATs or Firewall. >>>>> >>>>> The SIP-outbound mechanism also works with Mutual TLS. >>>>> >>>>> Therefore, for this case, I do not believe that their >>>>> mechanism is general enough to be standardized. >>>>> >>>>> This is described at lenght in the draft. >>>>> >>>>> >>>>> From != To in REGISTER (Third Party Registration) >>>>> ------------------------------------------------- >>>>> >>>>> Third party registration is problematic for both their >>>>> proposed solution, as well as for SIP-outbound. >>>>> >>>>> For SIP-outbound, well, it plainly doesn't work. >>>>> >>>>> For their proposed solution, it is a security problem >>>>> since it effectively allows a non-secure user (the "authority" >>>>> as you call it), to request that session be delivered securily. >>>>> Dr, Evil person could hijack the "authority" role and redirects >>>>> all sessions to wherever it wants, and the sessions would be >>>>> "secured" with Dr. Evil. >>>>> >>>>> Furthermore, their proposed solution would not work in this >>>>> case either with server-provided certificates, or if there >>>>> is a NAT or Firewall. Again, big problem. >>>>> >>>>> To me, it means that Third Party Registration is just plain >>>>> bad in a secure environment. >>>>> >>>>> In fact, I don't like the idea of allowing third party >>>>> registration to allow a UAC with AOR in p1 domain to >>>>> register a contact in a different domain (p2 in this case). >>>>> That contact is effectively an AOR. >>>>> >>>>> How would I solve the problem? >>>>> >>>>> I would expect the other UA (sip:someapplication@P2) to do it's >>>>> own registration in it's own domain P2, according to the rules >>>>> of it's >>>>> own domain. If P2 is using server-provided certificates, it >>>>> would >>>>> work (with Outbound). If a NAT is present, it would works as >>>>> well. >>>>> >>>>> Then, I would allow user "something@P1" to log in securily >>>>> on the Proxy (with HTTPS for example), and request routing to >>>>> be done to another address (in this case, >>>>> sip:someapplication@P@). >>>>> To ensure that P1 would use TLS to P2 (as they want), I'd just >>>>> put >>>>> a "User TLS" checkbox. >>>>> >>>>> That seems to me to be a lot less broken that trying to squeeze >>>>> it >>>>> into third-party REGISTER. >>>> This is getting closer to the P1->P2 hop, but its a bit of a > herring >>>> that >>>> you've separated 1st and 3rd party registration. I could have >>>> something@P1 >>>> in both to: and from: and still point it at application@P2. >>>> >>>> I understand where you are going with "make that a checkbox on >>>> somebody's GUI" and >>>> that's exactly what I'm saying isn't good enough. The preference >>>> needs to be reflected in the URI. >>>> >>>> For the registration case, binding things between P1 and P2, let me >>>> try yet another way to say this. >>>> >>>> It's in the field. >>>> People are USING it. >>>> We are trying to say "Don't do that" without giving an alternative >>>> that works in that scenario. >>>> We will be ignored unless we can present a clear and compelling >>>> reason why someone >>>> is putting life or limb at risk to do this (and I suspect we'll be >>>> ignored even then). >>>> >>>> I'm not sure I can make any such argument around just this > transport >>>> parameter. If we're >>>> going to allow someone to say "udp" or "tcp" in this case, >>>> its rather >>>> pointless to not let them >>>> say tls (with the appropriate caveats around not having the >>>> anchor in >>>> DNS to verify who >>>> you're talking to). >>>> >>>> I _can_ make an argument around the notion of putting state in that >>>> doesn't point directly to you, >>>> but that goes way way beyond just the transport parameter, and if >>>> we're going to go there, we >>>> need to start an entirely different conversation that will take the >>>> transport parameter completely >>>> off the table for _any_ transport. >>>> >>>> RjS >>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>>>> Sent: Monday, June 04, 2007 14:55 >>>>>> To: Audet, Francois (SC100:3055) >>>>>> Cc: Dean Willis; SIP IETF >>>>>> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >>>>>> thoughts on transport=tls? >>>>>> >>>>>> Ok - we're closer, but not quite together yet. >>>>>> >>>>>> Lets start with a different message from the UAC where the >>>>>> RURI is simply >>>>>> sip:something@P1 >>>>>> >>>>>> The authority for something@P1 (the person that might send a >>>>>> register request with that in the To: header) wants >>>> requests to go to >>>>>> sip:someapplication@P2 >>>>>> and they want it to go over TLS. What they'd _like_ to do is >>>>>> send a register request with a contact that says to use TLS, >>>>>> or at most, send a single URI to the operators of P1 that >>>>>> describes where to send requests that show up for something@P1. >>>>>> >>>>>> What tools do we give them to make the statement they want to > make? >>>>>> RjS >>>>>> >>>>>> >>>>>> >>>>>> On Jun 4, 2007, at 4:30 PM, Francois Audet wrote: >>>>>> >>>>>>>> This is exactly where we are disagreeing. >>>>>>>> >>>>>>>> How do you _tell_ P1 that you want to reach P2 using TLS >>>>>> in the first >>>>>>>> place. >>>>>>>> As I said elsewhere in the thread, I don't think leaving this >>>>>>>> unspecified ("you just do this with the configuration of the >>>>>>>> proxy") is the right answer. If you have DNS, you tell >>>> P1 about P2 >>>>>>>> using DNS. If you don't have DNS, using the transport >>>> parameter in >>>>>>>> the URI you hand it seems pretty natural. That's how >>>>>> you're going to >>>>>>>> tell it to use udp or tcp... >>>>>>> >>>>>>> I think I finally understand what you are saying... >>>>>>> >>>>>>> Say UAC sends request to Request-URI uas@p2;transport=tls. >>>>>>> >>>>>>> The transport parameter indicates that the resource in the >>>>>> request URI >>>>>>> (uas@p2) is the one that needs to be contacted with TLS. >>>>>> Therefore, it >>>>>>> would be the P1 -> P2 link that would use TLS in this case >>>>>> (since P2 >>>>>>> owns that domain). And P2 could use whatever it wants for P2 -> >>>>>>> uas@uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy >>>>>>> between P1 and P2) could use whatever they want. >>>>>>> >>>>>>> The use case would be where the UAC "trust" it own domain >>>>>> and does not >>>>>>> feel it necessary to use TLS, and/or the UAC "trusts" the target >>>>>>> domain for being responsible of that happens inside the >>>>>> target domain. >>>>>>> And finally, the UAC does not really care if there are >>>>>> other types of >>>>>>> proxies in the middle (not responsible for a specific >>>> domain), that >>>>>>> may not use TLS. >>>>>>> >>>>>>> While I understand that this is in theory something that could > be >>>>>>> solvable, I'm not sure why it is such an interesting case. >>>>>> Seems to me >>>>>>> it is only of value if the only "vulnerable" hop is the >>>> one between >>>>>>> the source and target domains, and if there are no other proxies >>>>>>> between them (e.g., no "Service provider"). >>>>>>> >>>>>>> In fact, it pretty much describes to me why you should be >>>>>> using SIPS >>>>>>> in the first place. >>>>>>> >>>>>>> Do we *really* want to reintroduce transport=tls for this case? >>>>>>> >>>>>>> Side note: I just want to point out that RFC 2543 did NOT >>>> allow the >>>>>>> presence of the transport parameter at all in a Request-URI >>>>>> and 2543 >>>>>>> servers would ignore it or remove it. >>>>>> >>>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 19:50:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvinV-0007UL-89; Tue, 05 Jun 2007 19:50:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvinT-0007UG-0q for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 19:50:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvinS-0007U8-NG for sip@ietf.org; Tue, 05 Jun 2007 19:50:42 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvinR-0007w4-GH for sip@ietf.org; Tue, 05 Jun 2007 19:50:42 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l55NoR802534; Tue, 5 Jun 2007 23:50:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Date: Tue, 5 Jun 2007 18:50:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C0CAF2@zrc2hxm0.corp.nortel.com> In-Reply-To: <4665EEED.7000708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? Thread-Index: Acenx6buwqalczs9S96hH1vTPAPRUQABGW7Q References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> <0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net> <4665EEED.7000708@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Gilad Shaham" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Normally, I would agree with you. But transport=3Dtls is so=20 intertwined with SIPS that I'd rather fix both at the same time. What I haven't heard is any voice strongly being against the=20 re-instatement of transport=3Dtls (except perhaps myself, but I don't=20 care anymore: just want to move on). > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, June 05, 2007 16:17 > To: Gilad Shaham > Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean Willis > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts ontransport=3Dtls? >=20 > Jumping in. I just happened to pick Gilad's message to respond to. >=20 > I've only been loosely following this discussion. But it=20 > seems to me that this transport=3Dtls issue is a distraction=20 > from finishing the sips draft. Why does the sips draft have=20 > any responsibility for addressing this issue? >=20 > I think it would be better to let the sips draft be finished=20 > and then move on to addressing all of the (many) important=20 > security issues that sips doesn't solve, as a separate effort. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 05 19:54:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvir2-0001cm-Uv; Tue, 05 Jun 2007 19:54:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvir1-0001ch-5Y for sip-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 19:54:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvir0-0001cZ-SN for sip@ietf.org; Tue, 05 Jun 2007 19:54:22 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvir0-0000pe-IH for sip@ietf.org; Tue, 05 Jun 2007 19:54:22 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l55NsJN26322; Tue, 5 Jun 2007 23:54:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Date: Tue, 5 Jun 2007 18:54:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C0CAF8@zrc2hxm0.corp.nortel.com> In-Reply-To: <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Thread-Index: AcentCdPpA1ZtiqpR7u4I75BiuJ9sgAGJMSg References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> From: "Francois Audet" To: "Jeroen van Bemmel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What we really need is a 302 that prohibits proxy recursion. That's out-of-scope of this draft IMHO.=20 > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 > Sent: Tuesday, June 05, 2007 13:55 > To: Audet, Francois (SC100:3055); sip@ietf.org > Subject: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of=20 > last hop exception >=20 > Francois, >=20 > Refer to RFC3261 16.5: if a proxy is not responsible for the=20 > request URI it MUST NOT recurse on 302 >=20 > 416 does not have the right semantics (since the endpoint may=20 > in fact support sips, proxies currently should never generate=20 > this response) and > RFC3261 section 16.7 step 4 says that a proxy responsible for=20 > the URI should recurse on it (should only happen in call=20 > forwarding scenarios, but still) >=20 > Lots of other error responses would prevent automatic=20 > recursion, but that does not make them any more suitable than=20 > 403 (which is not suitable either, > IMHO) >=20 > If you really want to be on the safe side, a new 4xx response=20 > code would be best >=20 > Regards, > Jeroen >=20 > Francois Audet wrote: > > Actually, 416 would achieve what you want. > > 302 would not be backward compatible because some proxy somewhere=20 > > could recurse on it, resulting in a downgrade. > > > > If people prefer a 416, I can put that. > > > > I do personaly prefer the 403, because I'd like to avoid any thing=20 > > that would cause a proxy to "automatically" recurse,=20 > thereby resulting=20 > > in a downgrade. > > > > ________________________________ > > > > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > > Sent: Monday, June 04, 2007 16:20 > > To: sip@ietf.org > > Cc: Audet, Francois (SC100:3055) > > Subject: draft-ietf-sip-sips-04: 403 instead of last hop exception > > > > > > In section 4.2 > > http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt > > proposes that a proxy should send 403 rather than apply the last hop > > exception. > > > > Instead, I would propose that it would send a 302 with either > > the registered Contact or the received request URI with a "sip:" > > scheme. 403 would be confusing, because the caller cannot=20 > distinguish > > between this case and the callee refusing his call. Perhaps a new > > response code (4xx Unsecure transport not allowed) would be better. > > > > Perhaps a caller preference should be defined to request such > > behavior, similar to "fork" and "no-fork" (RFC3841). Say=20 > "no-sips-sip" > > > > Regards, > > Jeroen=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 02:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp13-0001sP-HR; Wed, 06 Jun 2007 02:29:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvp11-0001sH-OP for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 02:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvp11-0001s9-Bs for sip@ietf.org; Wed, 06 Jun 2007 02:29:07 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvp0z-00047E-U6 for sip@ietf.org; Wed, 06 Jun 2007 02:29:07 -0400 Received: (qmail 17294 invoked by uid 0); 6 Jun 2007 06:28:43 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 6 Jun 2007 06:28:43 -0000 Message-ID: <001601c7a803$b1932fd0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Francois Audet" , "Paul Kyzivat" , "Gilad Shaham" References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com><0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net><4665EEED.7000708@cisco.com> <1ECE0EB50388174790F9694F77522CCF10C0CAF2@zrc2hxm0.corp.nortel.com> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughtsontransport=tls? Date: Wed, 6 Jun 2007 08:27:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I am strongly against it. If there are any issues that are currently being solved using transport=tls (in practice), they should be solved in a different way. Regards, Jeroen Francois Audet wrote: > Normally, I would agree with you. But transport=tls is so > intertwined with SIPS that I'd rather fix both at the same time. > > What I haven't heard is any voice strongly being against the > re-instatement of transport=tls (except perhaps myself, but I don't > care anymore: just want to move on). > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, June 05, 2007 16:17 >> To: Gilad Shaham >> Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean >> Willis Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last >> thoughts ontransport=tls? >> >> Jumping in. I just happened to pick Gilad's message to respond to. >> >> I've only been loosely following this discussion. But it >> seems to me that this transport=tls issue is a distraction >> from finishing the sips draft. Why does the sips draft have >> any responsibility for addressing this issue? >> >> I think it would be better to let the sips draft be finished >> and then move on to addressing all of the (many) important >> security issues that sips doesn't solve, as a separate effort. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 02:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpL9-00015Z-Ci; Wed, 06 Jun 2007 02:49:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvpL7-00015R-6q for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 02:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpL3-00015D-PW for sip@ietf.org; Wed, 06 Jun 2007 02:49:49 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvpL2-0007ox-GY for sip@ietf.org; Wed, 06 Jun 2007 02:49:49 -0400 Received: from kevlar.softarmor.com ([127.0.1.1] ident=dwillis) by kevlar.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1HvpNK-0000ad-93; Wed, 06 Jun 2007 01:52:10 -0500 Message-ID: <46665999.6090900@softarmor.com> Date: Wed, 06 Jun 2007 01:52:09 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> In-Reply-To: <18020.27378.227115.453498@tutpro.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: SIP IETF , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Francois Audet writes: > > > Later, in-dialog request will be sent on each hop reusing the existing > > established connections (TLS or TCP) as per current RFC 3261 > > procedures. > > what if established connection breaks for one reason or another and > needs to be re-established for routing in-dialog request? if there is > no transport info in request route, how does the proxy know which > transport to use? How about: It always tries TLS first, and if that doesn't work it either 1) falls back to something else or 2) gives up. The choice between 1 and 2 is made based on local policy. -- 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 sip-bounces@ietf.org Wed Jun 06 03:04:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpZT-0004RY-Vh; Wed, 06 Jun 2007 03:04:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvpZR-0004R1-AS for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 03:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvpZQ-0004Ox-Sh for sip@ietf.org; Wed, 06 Jun 2007 03:04:40 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvpZP-0000UM-Ie for sip@ietf.org; Wed, 06 Jun 2007 03:04:40 -0400 Received: from kevlar.softarmor.com ([127.0.1.1] ident=dwillis) by kevlar.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hvpbm-0001KF-2o; Wed, 06 Jun 2007 02:07:06 -0500 Message-ID: <46665D18.3010207@softarmor.com> Date: Wed, 06 Jun 2007 02:07:04 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Server srv records? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> <18021.38106.242640.743299@tutpro.com> In-Reply-To: <18021.38106.242640.743299@tutpro.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > clients are existing standard sip clients that not given anything else > but aor, username and password. then they automatically make srv query > on example.com, not on x.example.com. Most clients are configurable with AOR, default proxy, username, and password. If they aren't configurable with this, they're broken, they've always been broken, and you need new ones. Even web browsers can be configured to use a proxy that is not related to the user's AOR. Examples of clients configurable this way include my ancient 3Com phone, ancient Pingtel phone, every version of a Cisco 79xx phone I can remember using over the last seven years, Linksys PAP2, Linksys RTP31, etc. Some phones even learn their default proxies via DHCP. So to do what you want to do, configure two sets of SRV records, one that will be exercised by phones as "default proxies" and one that corresponds to the domain part of your AORs. -- 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 sip-bounces@ietf.org Wed Jun 06 03:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvpg3-0000hq-JW; Wed, 06 Jun 2007 03:11:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvpg1-0000hQ-GH for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 03:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvpg0-0000hI-VY for sip@ietf.org; Wed, 06 Jun 2007 03:11:28 -0400 Received: from sip.tutpro.com ([192.98.100.10] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvpfz-0001kd-Jp for sip@ietf.org; Wed, 06 Jun 2007 03:11:28 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id B67701EC68F; Wed, 6 Jun 2007 10:11:26 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHbbqAqByf2D; Wed, 6 Jun 2007 10:11:23 +0300 (EEST) Received: from taimen (telomeres84.gprs.dnafinland.fi [62.78.111.84]) by tutpro.com (Postfix) with ESMTP; Wed, 6 Jun 2007 10:11:23 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 61437AC145; Wed, 6 Jun 2007 10:11:17 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18022.24085.271641.635841@tutpro.com> Date: Wed, 6 Jun 2007 10:11:17 +0300 To: Dean Willis Subject: Re: [Sip] Server srv records? In-Reply-To: <46665D18.3010207@softarmor.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> <18021.38106.242640.743299@tutpro.com> <46665D18.3010207@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > Most clients are configurable with AOR, default proxy, username, and > password. If they aren't configurable with this, they're broken, they've > always been broken, and you need new ones. Even web browsers can be > configured to use a proxy that is not related to the user's AOR. yes, clients are configurable, but if sip is trying to compete with spype, xmpp, etc., configuration required by user must be minimal, nothing in addition to aor, username and password. all the rest must be automatically learned from the network. looks like you have lost totally touch of the real world, if you think that it is feasible to ask users to manually configure outbound proxies. -- 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 sip-bounces@ietf.org Wed Jun 06 04:44:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr86-0002vL-Oq; Wed, 06 Jun 2007 04:44:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvr84-0002tZ-UJ for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 04:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvr84-0002tR-A1 for sip@ietf.org; Wed, 06 Jun 2007 04:44:32 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvr82-0003ZT-Rg for sip@ietf.org; Wed, 06 Jun 2007 04:44:32 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 06 Jun 2007 01:44:30 -0700 X-IronPort-AV: i="4.16,388,1175497200"; d="scan'208"; a="14675141:sNHT43315696" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:44:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughtsontransport=tls? Date: Wed, 6 Jun 2007 09:44:26 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097E3B9@EMAILEMEA3.jnpr.net> In-Reply-To: <001601c7a803$b1932fd0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughtsontransport=tls? Thread-Index: AceoBAu1mj0NGOAdRrexYDh14a2ongAAlAeg References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com><0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net><4665EEED.7000708@cisco.com> <1ECE0EB50388174790F9694F77522CCF10C0CAF2@zrc2hxm0.corp.nortel.com> <001601c7a803$b1932fd0$0601a8c0@BEMBUSTER> From: "Gilad Shaham" To: "Jeroen van Bemmel" , "Francois Audet" , "Paul Kyzivat" X-OriginalArrivalTime: 06 Jun 2007 08:44:28.0930 (UTC) FILETIME=[E512A620:01C7A816] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I tried to develop my point a little further. I think there should be a way for the UA to specify the means of communication. If we support transport=3Dtls it resembles a little to = the transport parameter in the Via header. This is good as long as there single preference. This is always the case in Via header, but the transport parameter is not good enough in the following cases: * Registrations where outbound is not used and user has more than one preference on transport/security attributes. * Outgoing communication and the user has more than one preference on security attributes. (There are probably other cases which I'm not aware of) These preferences have some relationship with the transport. A UA might want to indicate it supports TLS over TCP and not TLS over SCTP. I think SIPS means - I want to communicate, possibly via trusted proxies, in a manner that a third-party would not be able to intercept or modify. If this definition is acceptable it does not rule out IPSec, despite being out of RFC 3261 scope (I'll open a different thread on that). My point is that this is also part of the possible preferences. A UA might indicate that it can communicate either in IPSec or TLS. In the transport parameter syntax the only option would be a single value such as "transport=3Dipsec-udp". Furthermore a UA might want to indicate it wants higher grade of security 128 and not 40 bits. I think the draft clarifies well the relationship between SIP and SIPS. If there is a need to handle the cases above, it should be done by other means. Bottom line is that it's likely we'll regret allowing the use of transport=3Dtls. From my understanding the draft tries to add backward compatibility and does not endorse it. > -----Original Message----- > From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] > Sent: Wednesday, June 06, 2007 9:27 AM > To: Francois Audet; Paul Kyzivat; Gilad Shaham > Cc: SIP IETF; Dean Willis > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > thoughtsontransport=3Dtls? >=20 > I am strongly against it. If there are any issues that are currently being > solved using transport=3Dtls (in practice), they should be solved in a > different way. >=20 > Regards, > Jeroen >=20 > Francois Audet wrote: > > Normally, I would agree with you. But transport=3Dtls is so > > intertwined with SIPS that I'd rather fix both at the same time. > > > > What I haven't heard is any voice strongly being against the > > re-instatement of transport=3Dtls (except perhaps myself, but I = don't > > care anymore: just want to move on). > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Tuesday, June 05, 2007 16:17 > >> To: Gilad Shaham > >> Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean > >> Willis Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last > >> thoughts ontransport=3Dtls? > >> > >> Jumping in. I just happened to pick Gilad's message to respond to. > >> > >> I've only been loosely following this discussion. But it > >> seems to me that this transport=3Dtls issue is a distraction > >> from finishing the sips draft. Why does the sips draft have > >> any responsibility for addressing this issue? > >> > >> I think it would be better to let the sips draft be finished > >> and then move on to addressing all of the (many) important > >> security issues that sips doesn't solve, as a separate effort. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 05:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvrNh-00051y-Ir; Wed, 06 Jun 2007 05:00:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvrNf-00051Q-T2 for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 05:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvrNf-00051I-JF for sip@ietf.org; Wed, 06 Jun 2007 05:00:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvrNe-0007d9-BE for sip@ietf.org; Wed, 06 Jun 2007 05:00:39 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 06 Jun 2007 02:00:37 -0700 X-IronPort-AV: i="4.16,388,1175497200"; d="scan'208"; a="14682267:sNHT33816950" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jun 2007 10:00:36 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2007 10:00:35 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097E3CA@EMAILEMEA3.jnpr.net> In-Reply-To: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIPS draft - Should SIPS and TLS be tightly coupled? Thread-Index: AcejnKlPI/BqqzcBSUukYUkKwWAkIAEesUSw References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> From: "Gilad Shaham" To: "Dean Willis" X-OriginalArrivalTime: 06 Jun 2007 09:00:36.0579 (UTC) FILETIME=[25D62B30:01C7A819] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: SIP IETF Subject: [Sip] SIPS draft - Should SIPS and TLS be tightly coupled? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, I have seen that the draft defines the relationship between SIP and SIPS and indicates that "A SIPS URI specifies that the resource be contacted securely." I believe that IPSec can also achieve the same goal in terms of security. My question is shouldn't this specification define this as an acceptable possibility. If 2 proxies have an IPSec tunnel between them, I believe it is acceptable that they would pass SIPS communication just like TLS communication. Naturally IPSec can also be used to pass SIP communication. Basically almost any rule that applies to TLS in the SIPS context, applies to IPSec. The reason I think this is required is the fact that there are SIP and IPSec implementations and SIPS is not defined for these cases. If this is accepted, it would mean the draft should indicate "secure transport" instead of "TLS" (except where TLS is specifically discussed). Regards, Gilad _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 09:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvGO-0007Z9-Cl; Wed, 06 Jun 2007 09:09:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvvGL-0007Yv-LI for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 09:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvGL-0007Yn-Bp for sip@ietf.org; Wed, 06 Jun 2007 09:09:21 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvvGK-0006zy-2D for sip@ietf.org; Wed, 06 Jun 2007 09:09:21 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l56D9FjK027439; Wed, 6 Jun 2007 08:09:15 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l56D9Fa06083; Wed, 6 Jun 2007 08:09:15 -0500 (CDT) Message-ID: <4666B1FB.4050201@alcatel-lucent.com> Date: Wed, 06 Jun 2007 08:09:15 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com><860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com><2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF10BBD886@zrc2hxm0.corp.nortel.com><1AB4CAB8-2B88-4AB9-96D9-2E6A1B4DA847@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBD970@zrc2hxm0.corp.nortel.com><46B5EE67-0A3C-4D18-95F1-B4A3A767CE2E@nostrum.com><1ECE0EB50388174790F9694F77522CCF10BBDA53@zrc2hxm0.corp.nortel.com> <0E48B768805E4D44A70709C8AE09209097E2F2@EMAILEMEA3.jnpr.net> <4665EEED.7000708@cisco.com> <1ECE0EB50388174790F9694F77522CCF10C0CAF2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10C0CAF2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > What I haven't heard is any voice strongly being against the > re-instatement of transport=tls (except perhaps myself, but I don't > care anymore: just want to move on). FWIW, and for the record, I am also against the re-instatement of "transport=tls" for much the same reasons that you had mentioned in a previous email (c.f. http://www1.ietf.org/mail-archive/web/sip/current/msg19371.html). Plus, now that TLS is supported over other transports, we will need to indicate the transport in the parameter as well. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 12:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvya4-0005SQ-TF; Wed, 06 Jun 2007 12:41:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvya2-0005RR-RI for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 12:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvya2-0005Qc-G5 for sip@ietf.org; Wed, 06 Jun 2007 12:41:54 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyYL-0001We-Vf for sip@ietf.org; Wed, 06 Jun 2007 12:40:12 -0400 Received: from kevlar.softarmor.com ([127.0.1.1] ident=dwillis) by kevlar.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hvyak-0003o0-4i; Wed, 06 Jun 2007 11:42:38 -0500 Message-ID: <4666E3FC.3000708@softarmor.com> Date: Wed, 06 Jun 2007 11:42:36 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Juha Heinanen Subject: Re: [Sip] Server srv records? References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> <18021.38106.242640.743299@tutpro.com> <46665D18.3010207@softarmor.com> <18022.24085.271641.635841@tutpro.com> In-Reply-To: <18022.24085.271641.635841@tutpro.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Juha Heinanen wrote: > Dean Willis writes: > > > Most clients are configurable with AOR, default proxy, username, and > > password. If they aren't configurable with this, they're broken, they've > > always been broken, and you need new ones. Even web browsers can be > > configured to use a proxy that is not related to the user's AOR. > > yes, clients are configurable, but if sip is trying to compete with > spype, xmpp, etc., configuration required by user must be minimal, > nothing in addition to aor, username and password. all the rest must be > automatically learned from the network. > > looks like you have lost totally touch of the real world, if you think > that it is feasible to ask users to manually configure outbound proxies. My former employers shipped something like 50 million "configurable" SIP devices to the real world, and email and http clients require comparable configuration. I also know that at many places one has to manually configure something like a SOCKs proxy to make XMPP work. The human-controlled policies around network operations require systems to act in more complex ways than protocols can optimally support. This isn't the protocol's fault. -- 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 sip-bounces@ietf.org Wed Jun 06 12:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvyaw-00062I-0r; Wed, 06 Jun 2007 12:42:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hvyau-00061I-6Y for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 12:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvyat-00060R-SW for sip@ietf.org; Wed, 06 Jun 2007 12:42:47 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvyar-0003JS-JE for sip@ietf.org; Wed, 06 Jun 2007 12:42:47 -0400 Received: from kevlar.softarmor.com ([127.0.1.1] ident=dwillis) by kevlar.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1HvydG-0003w6-5K; Wed, 06 Jun 2007 11:45:14 -0500 Message-ID: <4666E498.7080106@softarmor.com> Date: Wed, 06 Jun 2007 11:45:12 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Gilad Shaham References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <0E48B768805E4D44A70709C8AE09209097E3CA@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097E3CA@EMAILEMEA3.jnpr.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP IETF Subject: [Sip] Re: SIPS draft - Should SIPS and TLS be tightly coupled? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gilad Shaham wrote: > Hi Dean, > > I have seen that the draft defines the relationship between SIP and SIPS > and indicates that "A SIPS URI specifies that the resource be contacted > securely." > > I believe that IPSec can also achieve the same goal in terms of > security. My question is shouldn't this specification define this as an > acceptable possibility. > I initially supported this position, but the WG has stepped back from it FOR THIS DRAFT in the interest of making SIPS as meaningful as we can without heavy modification to the protocol (and with some realization that SIPS alone doesn't mean all that much). Your suggestion is slipping into "futures" work problems, much like the cypher-suites draft. -- 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 sip-bounces@ietf.org Wed Jun 06 12:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyfE-00076D-6A; Wed, 06 Jun 2007 12:47:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HvyfD-000767-B3 for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 12:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyfD-00075z-1Z for sip@ietf.org; Wed, 06 Jun 2007 12:47:15 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyfB-0005Qs-MH for sip@ietf.org; Wed, 06 Jun 2007 12:47:15 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id C51001EC68F; Wed, 6 Jun 2007 19:47:12 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJWSsfnb6yzS; Wed, 6 Jun 2007 19:47:09 +0300 (EEST) Received: from taimen (isozyme251.gprs.dnafinland.fi [62.78.107.251]) by tutpro.com (Postfix) with ESMTP; Wed, 6 Jun 2007 19:47:08 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 1EF9FAC12D; Wed, 6 Jun 2007 19:47:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18022.58629.94232.137155@tutpro.com> Date: Wed, 6 Jun 2007 19:47:01 +0300 To: Dean Willis Subject: Re: [Sip] Server srv records? In-Reply-To: <4666E3FC.3000708@softarmor.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <016901c7a6d3$8f1e0cd0$06c8000a@acmepacket.com> <1ECE0EB50388174790F9694F77522CCF10BBD55E@zrc2hxm0.corp.nortel.com> <8E1A2FA9-02DD-4BF5-A28E-FC337FA7F82F@nostrum.com> <18020.29409.16674.687762@tutpro.com> <2465D84E-6669-4FBA-932E-FBE2DAA26130@nostrum.com> <18020.30897.464008.26643@tutpro.com> <839C1A78-7130-48F8-AF88-8A16099A6F33@nostrum.com> <18020.32366.567052.462492@tutpro.com> <009801c7a6ee$35c63d40$0601a8c0@BEMBUSTER> <18021.26876.281550.48449@tutpro.com> <002b01c7a78f$bda6dde0$0601a8c0@BEMBUSTER> <18021.38106.242640.743299@tutpro.com> <46665D18.3010207@softarmor.com> <18022.24085.271641.635841@tutpro.com> <4666E3FC.3000708@softarmor.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis writes: > The human-controlled policies around network operations require systems > to act in more complex ways than protocols can optimally support. This > isn't the protocol's fault. i agree that there are always cases where auto-configuration does not work, but it should be the default. auto-learning of outbound proxies should be a very basic requirement of outbound, but last time i checked, no mechanism was included. i suggest that a similar mechanism that xmpp has, will be added. -- 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 sip-bounces@ietf.org Wed Jun 06 14:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0Nt-0005DK-5u; Wed, 06 Jun 2007 14:37:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hw0Nq-0005CR-I3 for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 14:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0Nq-0005CJ-89 for sip@ietf.org; Wed, 06 Jun 2007 14:37:26 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw0No-0002QP-VC for sip@ietf.org; Wed, 06 Jun 2007 14:37:26 -0400 Received: from 206-176-144-212.waymark.net ([206.176.144.212]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hw0QC-0001TT-A3; Wed, 06 Jun 2007 13:39:52 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 6 Jun 2007 13:37:09 -0500 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Cullen Jennings , Keith Drage Subject: [Sip] Anybody reading draft-ietf-sip-saml-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > 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 SAML Profile and Binding > Author(s) : H. Tschofenig, et al. > Filename : draft-ietf-sip-saml-02.txt > Pages : 46 > Date : 2007-5-29 So does anybody besides the authors care, or is this work just so far ahead of the mainstream working group that we need to move the work to a lower priority queue? -- 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 sip-bounces@ietf.org Wed Jun 06 15:39:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Lg-0007UL-Ke; Wed, 06 Jun 2007 15:39:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hw1Le-0007UD-74 for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 15:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1Ld-0007U5-Te for sip@ietf.org; Wed, 06 Jun 2007 15:39:13 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw1Lc-0000vN-KY for sip@ietf.org; Wed, 06 Jun 2007 15:39:13 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l56JdBhc009115; Wed, 6 Jun 2007 14:39:11 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l56Jd2a09482; Wed, 6 Jun 2007 14:39:11 -0500 (CDT) Message-ID: <46670D56.6060803@alcatel-lucent.com> Date: Wed, 06 Jun 2007 14:39:02 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > So does anybody besides the authors care, or is this work just so far > ahead of the mainstream working group that we need to move the work to > a lower priority queue? I had read and commented on earlier revision of this work; have not had the chance to see -02 yet. So, to be pedantic about a three questions in your short paragraph above: 1) Does anybody besides the authors care? Yes. 2) Is this work so far ahed of the mainstream working group? Given that we are fighting sips, transport=tls, SRV RR, MIME, and SDP rules battles in the last couple of weeks, I would say yes. 3) Do we need to move the work to a lower priority queue? I will leave that in the capable hands of Messers Willis and Drage to decide ;-) - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 16:14:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1tr-0000WH-6C; Wed, 06 Jun 2007 16:14:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hw1tp-0000UL-D4 for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 16:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw1to-0000Rh-10 for sip@ietf.org; Wed, 06 Jun 2007 16:14:32 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw1tf-00033b-AO for sip@ietf.org; Wed, 06 Jun 2007 16:14:31 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l56KEID15326; Wed, 6 Jun 2007 20:14:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Wed, 6 Jun 2007 15:14:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> In-Reply-To: <46665999.6090900@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: AceoBuBZq8yBp0IvQ5ysE7QxNkeanwAcDYiA References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <46665999.6090900@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sounds appealing, until you realize that in an environment where TLS support is the exception and not the norm, you would degrade the performance of the network significantly by having lots of failed TLS connection attemps. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Tuesday, June 05, 2007 23:52 > To: Juha Heinanen > Cc: Audet, Francois (SC100:3055); SIP IETF > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 > Juha Heinanen wrote: > > Francois Audet writes: > >=20 > > > Later, in-dialog request will be sent on each hop reusing the=20 > > existing > established connections (TLS or TCP) as per current RFC=20 > > 3261 > procedures. > >=20 > > what if established connection breaks for one reason or another and=20 > > needs to be re-established for routing in-dialog request? =20 > if there is=20 > > no transport info in request route, how does the proxy know which=20 > > transport to use? >=20 > How about: >=20 > It always tries TLS first, and if that doesn't work it either=20 > 1) falls back to something else or 2) gives up. The choice=20 > between 1 and 2 is made based on local policy. >=20 > -- > Dean >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 06 18:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4S7-0002zH-0J; Wed, 06 Jun 2007 18:58:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hw4S5-0002z9-CZ for sip-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4S5-0002z1-30 for sip@ietf.org; Wed, 06 Jun 2007 18:58:05 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4S2-0008Kx-Px for sip@ietf.org; Wed, 06 Jun 2007 18:58:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l56Mvxk28621; Wed, 6 Jun 2007 22:58:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Wed, 6 Jun 2007 17:57:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C659AC@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Thread-Index: AceoBuBZq8yBp0IvQ5ysE7QxNkeanwAcDYiAAAQ4VdA= References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <46665999.6090900@softarmor.com> <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Dean Willis" , "Juha Heinanen" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, now that I think of it, it may not be as bad as I tought. If UAs are using sip-outbound with their proxies, it would handle the vast majority of the links. Between proxies, you would use DNS or static configuration normally. Furthermore, between proxies, re-using of existing TCP/TLS may also be done. So maybe you are right. > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Wednesday, June 06, 2007 13:14 > To: Dean Willis; Juha Heinanen > Cc: SIP IETF > Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on transport=3Dtls? >=20 > Sounds appealing, until you realize that in an environment=20 > where TLS support is the exception and not the norm, you=20 > would degrade the performance of the network significantly by=20 > having lots of failed TLS connection attemps. >=20 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, June 05, 2007 23:52 > > To: Juha Heinanen > > Cc: Audet, Francois (SC100:3055); SIP IETF > > Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last=20 > thoughts on=20 > > transport=3Dtls? > >=20 > > Juha Heinanen wrote: > > > Francois Audet writes: > > >=20 > > > > Later, in-dialog request will be sent on each hop reusing the=20 > > > existing > established connections (TLS or TCP) as per=20 > current RFC > > > 3261 > procedures. > > >=20 > > > what if established connection breaks for one reason or=20 > another and=20 > > > needs to be re-established for routing in-dialog request? > > if there is > > > no transport info in request route, how does the proxy know which=20 > > > transport to use? > >=20 > > How about: > >=20 > > It always tries TLS first, and if that doesn't work it either > > 1) falls back to something else or 2) gives up. The choice=20 > between 1=20 > > and 2 is made based on local policy. > >=20 > > -- > > Dean > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 00:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9ZR-0007Uc-4M; Thu, 07 Jun 2007 00:26:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hw9ZP-0007UX-Ua for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 00:26:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw9ZP-0007UN-KY for sip@ietf.org; Thu, 07 Jun 2007 00:25:59 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw9ZN-0000aT-Ju for sip@ietf.org; Thu, 07 Jun 2007 00:25:59 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hw9bm-0004vG-J1; Wed, 06 Jun 2007 23:28:26 -0500 In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10C659AC@zrc2hxm0.corp.nortel.com> References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <46665999.6090900@softarmor.com> <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10C659AC@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73365FF2-82EA-43C4-8041-AF079E13B1F5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts on transport=tls? Date: Wed, 6 Jun 2007 23:25:41 -0500 To: Francois Audet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP IETF , Juha Heinanen X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois said: > Actually, now that I think of it, it may not be as bad as I tought. > > If UAs are using sip-outbound with their proxies, it would handle the > vast majority of the links. > > Between proxies, you would use DNS or static configuration normally. > > Furthermore, between proxies, re-using of existing TCP/TLS may also be > done. > > So maybe you are right > > Dean Said: >> It always tries TLS first, and if that doesn't work it either >> 1) falls back to something else or 2) gives up. The choice > between 1 >> and 2 is made based on local policy. I think many of the assumptions we've been making seem to indicate that if you just don't know, the only reasonable thing to do is try TLS first. If there's nobody listening on the TLS port (but somebody at the IP address), you should get an ICMP response pretty quickly anyhow, then be able to decide on fallback. If we hold the opposite true, and we try plain SIP/UDP first and only move to TLS when plain SIP fails, we're going to be in for a world of delay-hurt (waiting for that plain SIP/UDP transaction to time out) and never opportunistically using TLS anyhow. Of course, it's better if you "know" up front, which is part of what the argument in favor of transport=tls is asking for. But given that we have ways for knowing in many of the other cases, this may not be critical. Of course, if we'd started with a plain connection, discovered TLS capability in a greeting message (aka EHELO) and then done an upgrade to that connection using something like STARTTLS, we wouldn't be having this discussion. It would have just worked. Boy do I feel dumb. -- 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 sip-bounces@ietf.org Thu Jun 07 06:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFWv-0000uI-Fv; Thu, 07 Jun 2007 06:47:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwFWF-0006kX-Ho for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 06:47:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFWD-0006gm-NJ for sip@ietf.org; Thu, 07 Jun 2007 06:47:05 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwFWC-0002wT-Gp for sip@ietf.org; Thu, 07 Jun 2007 06:47:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57AkXNZ003078; Thu, 7 Jun 2007 13:46:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:46:47 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:46:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Date: Thu, 7 Jun 2007 13:46:46 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03C807DA@esebe103.NOE.Nokia.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Thread-Index: AcdjV5vAXxGSnwWIRQ2Zy3wLPXZBURETaYiQAFGd0lA= References: <20070310210143.466231CC77@delta.rtfm.com> <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> From: To: X-OriginalArrivalTime: 07 Jun 2007 10:46:47.0055 (UTC) FILETIME=[255969F0:01C7A8F1] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Steve, I tried to understand how the modified digest algorithm in your draft works and I have to admit I have difficulties on digesting it. First of all your draft tells that the UA should create the request-digest as follows: Once the data string is formed, it MUST be hashed and signed with private key of the client. The algorithm used for hashing and signing is specified in the WWW-Authenticate header. To verify the received request-digest the server should then do this: 6. The server authenticates the client by generating its own challenge response using the server and client generated data and compares its result with that sent in the challenge response by the client. If the two match, the client has been authenticated. and: the server must perform the same cryptographic operation performed by the client, and compare the result to the response provided by the client. But how can the server perform the same cryptograpic operation as the client ? Only the client knows its private key used for creating request-digest while the server knows only the public key of the user. The method that you are suggesting would work if there is a shared secret like in RFC 2617 for HTTP Digest but this is not the case for using PKI certificates. If I have understood it correctly how the digital signatures are used the process should instead go like this: 1. The UA creates a hash of the SIP request and the nonce 2. The UA encrypts the resulting hash with its private key and sends this digital signature along with the SIP request 3. The server also creates a hash of the SIP request and the nonce 4. The server decrypts the encrypted string with the public key and compares the result to the hash it created in step 3. Please tell if you think I have misunderstood any of this. I did not find the draft to describe very clearly how the digital signing with the private key is performed and which algorithms are used in different phases of the process. Thus my further questions=20 are related to the hashing functions introduced in your draft: this document, in order to remain consistent with RFC 2617, the string obtained by applying the algorithm to the data "data" will be denoted by KD(data)and the string obtained by applying the hash algorithm to the data "data" will be denoted H(data). The algorithm used for hashing and signing is specified in the WWW-Authenticate header. This document defines only one "algorithm" value: 'rsa-sha1' Does this mean that rsa-sha1 is used for both H(data) and KD(data) ? If yes, what is then the difference between functions H and KD ? Or is H(data) supposed to use MD5 instead of rsa-sha1 ?=20 Is usage of the private key somehow embedded into your definition=20 of KD(data) or is signing applied to the hashed string that is received as a result from KD(data) ? Regards, Erkki >-----Original Message----- >From: ext Steve Dotson [mailto:S.Dotson@CableLabs.com]=20 >Sent: 05.June.2007 22:13 >To: EKR; sip@ietf.org >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Eric, thank you for the comments and sorry for the slow response. > >As you stated this was a first draft solution based on >draft-dotson-sip-certificate-auth. We have since updated the >requirements draft to -03 which can be found at >http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat >e-auth-03 >.txt. > >The reasoning behind choosing a challenge/response paradigm is that is >the current model used in SIP, and allows a registrar to control when >and if to authenticate UAs. S/MIME could be a potential mechanism, as >could Identity or AIB in theory. At a high-level we weren't as=20 >concerned >with the actual mechanism as the signaling and messaging, since the >signing of some set of data seems to be similar across all the current >solutions. What we seem to be missing is the signaling and messaging to >use certificates for authenticating to a registrar/network or another >UA. Without challenge/response, the UA would always need to do >cryptographic processing and messages are larger, whether or not the >other end is requiring authentication. For UA to UA authentication, the >issue is even more of a concern, as we don't want UAs assuming >authentication of every dialog request. > >Is it a fair statement that S/MIME/AIB/Identity all use similar >cryptographic tools but vary in the specific data from the=20 >dialog chosen >to sign?=20 > >Is there any preference to which "mechanism" is used for the solution? > >Do all the solutions have issues with middleboxes? > >Thanks. > >Steve. >=20 > >-----Original Message----- >From: EKR [mailto:ekr@networkresonance.com]=20 >Sent: Saturday, March 10, 2007 2:02 PM >To: sip@ietf.org >Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >$Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1 2007/03/10 >21:13:10 ekr Exp $ > >The native SIP authentication scheme is Digest authentication. This >draft and its companion draft-dotson-sip-certificate-auth argue that it >is desirable to have an authentication scheme based on public key >certificates that can span multiple hops (TLS client auth lets you >authenticate to the first hop proxy). To some extent, SIP already has >such a scheme: messages can be S/MIME signed. As I understand it, the >primary deficiencies claimed for S/MIME are: > >- There is no way for the server to indicate he wants you to > S/MIME sign. >- There is no built-in defense against replay attacks. > >In order to correct this situation, this draft proposes an extension to >HTTP Digest to add a signature mode. I'm not sure how important this >problem actually is, but I'm skeptical that this draft is the best way >to go about it. > >It seems to me that this proposal confuses two issues: > >1. The formatting of the signature over the data. >2. How the server indicates that it wants a signature. > >This proposal addresses both, but its solution to (1) is clumsy and >replicates functionality we already have, namely S/MIME. >It's fine to define a new form of authentication challenge that says >"please sign with your S/MIME cert" and even have it include a nonce, >but there's no need to model the response on Digest auth. >You can simply include the challenge in the material you sign over. > >Incidentally, I've heard people argue that it would be nice to have a >generic solution for both HTTP and SIP. This problem has already been >attacked for HTTP (though with minimal adoption). See S-HTTP=20 >(RFC 2660). > >-Ekr > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 07:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFjI-0002xg-Bz; Thu, 07 Jun 2007 07:00:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwFjG-0002xV-39 for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 07:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwFjF-0002xM-Pw for sip@ietf.org; Thu, 07 Jun 2007 07:00:33 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwFjE-0007yC-A9 for sip@ietf.org; Thu, 07 Jun 2007 07:00:33 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57B06Ke005336; Thu, 7 Jun 2007 14:00:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:00:05 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:00:05 +0300 Received: from [172.21.154.97] ([172.21.154.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:00:05 +0300 Message-ID: <4667E535.70302@nsn.com> Date: Thu, 07 Jun 2007 14:00:05 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 11:00:05.0848 (UTC) FILETIME=[01778D80:01C7A8F3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: SIP IETF , Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > So does anybody besides the authors care, Yes, I care, I think this is an important functionality that we ought to do. > or is this work just so far > ahead of the mainstream working group that we need to move the work to a > lower priority queue? Probably there are other more important topics. In general, we should give higher priority to fixing the current protocol than adding new functionality, but this does not advocate for stopping progressing new functions until the protocol is totally fixed. /Miguel > > > -- > 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 > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, 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 sip-bounces@ietf.org Thu Jun 07 08:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH1o-0008RU-DJ; Thu, 07 Jun 2007 08:23:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwH1l-0008P6-EL for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 08:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH1l-0008OY-37 for sip@ietf.org; Thu, 07 Jun 2007 08:23:45 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwH0l-0004hG-EX for sip@ietf.org; Thu, 07 Jun 2007 08:22:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l57CMMBv004692; Thu, 7 Jun 2007 15:22:36 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:22:26 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 15:22:26 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Anybody reading draft-ietf-sip-saml-02.txt Date: Thu, 7 Jun 2007 15:22:26 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03C80922@esebe103.NOE.Nokia.com> In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Anybody reading draft-ietf-sip-saml-02.txt Thread-Index: AceoacYIcxT5O9KtRlynXtaiNuGRXgAlCtJg References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> From: To: , X-OriginalArrivalTime: 07 Jun 2007 12:22:26.0532 (UTC) FILETIME=[82581A40:01C7A8FE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: fluffy@cisco.com, drage@alcatel-lucent.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have also read the draft and to me it seems to be in a rather good shape. It is worth checking whether the spec could even be completed soon, instead of letting it just to wait for better times to appear. Regards, Erkki >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 06.June.2007 21:37 >To: SIP IETF >Cc: Cullen Jennings; Keith Drage >Subject: [Sip] Anybody reading draft-ietf-sip-saml-02.txt=20 > > >On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol =20 >> Working Group of the IETF. >> >> Title : SIP SAML Profile and Binding >> Author(s) : H. Tschofenig, et al. >> Filename : draft-ietf-sip-saml-02.txt >> Pages : 46 >> Date : 2007-5-29 > > >So does anybody besides the authors care, or is this work just so far =20 >ahead of the mainstream working group that we need to move the work =20 >to a lower priority queue? > > >-- >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 sip-bounces@ietf.org Thu Jun 07 12:02:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKR5-0004tT-J4; Thu, 07 Jun 2007 12:02:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwKR4-0004pS-Ey for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKR4-0004n5-3w for sip@ietf.org; Thu, 07 Jun 2007 12:02:06 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKR2-0004FW-OS for sip@ietf.org; Thu, 07 Jun 2007 12:02:06 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l57G23Gj025890; Thu, 7 Jun 2007 10:02:03 -0600 (MDT) Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 7 Jun 2007 10:02:02 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Date: Thu, 7 Jun 2007 10:02:02 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C617EF12@srvxchg3.cablelabs.com> In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03C807DA@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Thread-Index: AcdjV5vAXxGSnwWIRQ2Zy3wLPXZBURETaYiQAFGd0lAADBOfgA== References: <20070310210143.466231CC77@delta.rtfm.com> <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> <8B1D53AEF7B03449A6D3771B3B7F850F03C807DA@esebe103.NOE.Nokia.com> From: "Steve Dotson" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks Erkki for the thorough review. Responses inline...=20 -----Original Message----- From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 Sent: Thursday, June 07, 2007 4:47 AM To: Steve Dotson Cc: ekr@networkresonance.com; sip@ietf.org Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Hi Steve, I tried to understand how the modified digest algorithm in your draft works and I have to admit I have difficulties on digesting it. First of all your draft tells that the UA should create the request-digest as follows: Once the data string is formed, it MUST be hashed and signed with private key of the client. The algorithm used for hashing and signing is specified in the WWW-Authenticate header. To verify the received request-digest the server should then do this: 6. The server authenticates the client by generating its own challenge response using the server and client generated data and compares its result with that sent in the challenge response by the client. If the two match, the client has been authenticated. and: the server must perform the same cryptographic operation performed by the client, and compare the result to the response provided by the client. But how can the server perform the same cryptograpic operation as the client ? Only the client knows its private key used for creating request-digest while the server knows only the public key of the user. The method that you are suggesting would work if there is a shared secret like in RFC 2617 for HTTP Digest but this is not the case for using PKI certificates. If I have understood it correctly how the digital signatures are used the process should instead go like this: 1. The UA creates a hash of the SIP request and the nonce 2. The UA encrypts the resulting hash with its private key and sends this digital signature along with the SIP request 3. The server also creates a hash of the SIP request and the nonce 4. The server decrypts the encrypted string with the public key and compares the result to the hash it created in step 3. Please tell if you think I have misunderstood any of this. [SD] You are correct. This should be clarified. I did not find the draft to describe very clearly how the digital signing with the private key is performed and which algorithms are used in different phases of the process. Thus my further questions are related to the hashing functions introduced in your draft: this document, in order to remain consistent with RFC 2617, the string obtained by applying the algorithm to the data "data" will be denoted by KD(data)and the string obtained by applying the hash algorithm to the data "data" will be denoted H(data). The algorithm used for hashing and signing is specified in the WWW-Authenticate header. This document defines only one "algorithm" value: 'rsa-sha1' Does this mean that rsa-sha1 is used for both H(data) and KD(data) ? If yes, what is then the difference between functions H and KD ? Or is H(data) supposed to use MD5 instead of rsa-sha1 ?=20 Is usage of the private key somehow embedded into your definition of KD(data) or is signing applied to the hashed string that is received as a result from KD(data) ? [SD] It appears the H(data) is unnecessary, KD could denote the hashing and encrypting (signing) of the string of data. I was attempting to work within the constraints of Digest's current procedures and call flows while re-using some existing concepts from Identity/AIB/etc. It would be helpful to get your feedback on the concept itself, whether you see challenge/response as the appropriate paradigm, and whether we should attempt to reuse existing mechanisms such as S/MIME, as there have been different views on these topics. Regards, Erkki >-----Original Message----- >From: ext Steve Dotson [mailto:S.Dotson@CableLabs.com] >Sent: 05.June.2007 22:13 >To: EKR; sip@ietf.org >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Eric, thank you for the comments and sorry for the slow response. > >As you stated this was a first draft solution based on=20 >draft-dotson-sip-certificate-auth. We have since updated the=20 >requirements draft to -03 which can be found at=20 >http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat >e-auth-03 >.txt. > >The reasoning behind choosing a challenge/response paradigm is that is=20 >the current model used in SIP, and allows a registrar to control when=20 >and if to authenticate UAs. S/MIME could be a potential mechanism, as=20 >could Identity or AIB in theory. At a high-level we weren't as=20 >concerned with the actual mechanism as the signaling and messaging,=20 >since the signing of some set of data seems to be similar across all=20 >the current solutions. What we seem to be missing is the signaling and=20 >messaging to use certificates for authenticating to a registrar/network >or another UA. Without challenge/response, the UA would always need to=20 >do cryptographic processing and messages are larger, whether or not the >other end is requiring authentication. For UA to UA authentication, the >issue is even more of a concern, as we don't want UAs assuming=20 >authentication of every dialog request. > >Is it a fair statement that S/MIME/AIB/Identity all use similar=20 >cryptographic tools but vary in the specific data from the dialog=20 >chosen to sign? > >Is there any preference to which "mechanism" is used for the solution? > >Do all the solutions have issues with middleboxes? > >Thanks. > >Steve. >=20 > >-----Original Message----- >From: EKR [mailto:ekr@networkresonance.com] >Sent: Saturday, March 10, 2007 2:02 PM >To: sip@ietf.org >Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >$Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1 2007/03/10=20 >21:13:10 ekr Exp $ > >The native SIP authentication scheme is Digest authentication. This=20 >draft and its companion draft-dotson-sip-certificate-auth argue that it >is desirable to have an authentication scheme based on public key=20 >certificates that can span multiple hops (TLS client auth lets you=20 >authenticate to the first hop proxy). To some extent, SIP already has=20 >such a scheme: messages can be S/MIME signed. As I understand it, the=20 >primary deficiencies claimed for S/MIME are: > >- There is no way for the server to indicate he wants you to > S/MIME sign. >- There is no built-in defense against replay attacks. > >In order to correct this situation, this draft proposes an extension to >HTTP Digest to add a signature mode. I'm not sure how important this=20 >problem actually is, but I'm skeptical that this draft is the best way=20 >to go about it. > >It seems to me that this proposal confuses two issues: > >1. The formatting of the signature over the data. >2. How the server indicates that it wants a signature. > >This proposal addresses both, but its solution to (1) is clumsy and=20 >replicates functionality we already have, namely S/MIME. >It's fine to define a new form of authentication challenge that says=20 >"please sign with your S/MIME cert" and even have it include a nonce,=20 >but there's no need to model the response on Digest auth. >You can simply include the challenge in the material you sign over. > >Incidentally, I've heard people argue that it would be nice to have a=20 >generic solution for both HTTP and SIP. This problem has already been=20 >attacked for HTTP (though with minimal adoption). See S-HTTP (RFC=20 >2660). > >-Ekr > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 12:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL7l-0004RW-KC; Thu, 07 Jun 2007 12:46:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwL7k-0004RH-5t for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwL7j-0004Qp-QF for sip@ietf.org; Thu, 07 Jun 2007 12:46:11 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwL7i-0000Wp-Fz for sip@ietf.org; Thu, 07 Jun 2007 12:46:11 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l57Gk7A01939; Thu, 7 Jun 2007 16:46:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Anybody reading draft-ietf-sip-saml-02.txt Date: Thu, 7 Jun 2007 11:45:53 -0500 Message-ID: In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Anybody reading draft-ietf-sip-saml-02.txt thread-index: AceoacWvZNN1P6ufRK6+aqKXOl10RgAuRJ/A From: "Mary Barnes" To: "Dean Willis" , "SIP IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Per other responses, there are people that care about this work. But, unfortunately, it is a bit ahead of the mainstream. However, I think it is important and I would hate to see it linger forever in the WG (it has already been around for a while). How far is it from being done?=20 Mary -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Wednesday, June 06, 2007 1:37 PM To: SIP IETF Cc: Cullen Jennings; Keith Drage Subject: [Sip] Anybody reading draft-ietf-sip-saml-02.txt On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol =20 > Working Group of the IETF. > > Title : SIP SAML Profile and Binding > Author(s) : H. Tschofenig, et al. > Filename : draft-ietf-sip-saml-02.txt > Pages : 46 > Date : 2007-5-29 So does anybody besides the authors care, or is this work just so far =20 ahead of the mainstream working group that we need to move the work =20 to a lower priority queue? -- 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 sip-bounces@ietf.org Thu Jun 07 15:21:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNYA-0003ie-K4; Thu, 07 Jun 2007 15:21:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwNY9-0003iY-Av for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 15:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNY9-0003iA-14 for sip@ietf.org; Thu, 07 Jun 2007 15:21:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwNY7-0005zM-MH for sip@ietf.org; Thu, 07 Jun 2007 15:21:37 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2007 12:21:36 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="377893547:sNHT48349354" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l57JLZTe030909; Thu, 7 Jun 2007 12:21:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57JLY20024380; Thu, 7 Jun 2007 19:21:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:21:34 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:21:34 -0700 Message-ID: <46685ABD.7080101@cisco.com> Date: Thu, 07 Jun 2007 15:21:33 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> In-Reply-To: <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 19:21:34.0589 (UTC) FILETIME=[0FC112D0:01C7A939] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1303; t=1181244095; x=1182108095; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20draft-ietf-sip-sips-04=3A=20403=20ins tead=20of=20last=20hop=20exception |Sender:=20; bh=uFCkGNdeCwW65o+cxaXLYQZ6oGk/A6aMbyqrDJWMDsY=; b=Oe09UwUDEsDoMbfZ58Ggr+pr4yQskebbMoLQSBnBm9ZLwuAbHC1N0I5mm+PMz+/SHApU/6cz j9elT0rEP1ydCQaBsCPg1DEgYhXFy9B6id8rtwEkJXt5xFPEUxzyQNsBFYVG1Lxub67W9u7BB4 N2QQgrqIRdttnwVKuxreCniPE=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Francois, > > Refer to RFC3261 16.5: if a proxy is not responsible for the request URI > it MUST NOT recurse on 302 It most certainly does not say that. Perhaps you are referring to this text: 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. This is referring to the R-URI in the original INVITE, not the one in the contact in the 3xx. > > 416 does not have the right semantics (since the endpoint may in fact > support sips, proxies currently should never generate this response) WHy is that? Section 21.4.14 says nothing about UA vs. proxies. It talks about servers. I think 416 is not far off. However to be honest we need to explicitly indicate that the problem was sips-to-sip so that the original UA can decide whether to retry. Thus I'd suggest a new 4xx code. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Jun 07 15:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNi1-00012U-Ir; Thu, 07 Jun 2007 15:31:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwNhz-0000wP-Ro for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 15:31:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwNhz-0000wH-IA for sip@ietf.org; Thu, 07 Jun 2007 15:31:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwNhz-0002rV-0t for sip@ietf.org; Thu, 07 Jun 2007 15:31:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Jun 2007 12:31:46 -0700 X-IronPort-AV: i="4.16,395,1175497200"; d="scan'208"; a="2194584:sNHT23996772" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l57JVke1011635; Thu, 7 Jun 2007 12:31:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l57JViaI017563; Thu, 7 Jun 2007 19:31:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:31:44 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 12:31:44 -0700 Message-ID: <46685D1F.8040306@cisco.com> Date: Thu, 07 Jun 2007 15:31:43 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> In-Reply-To: <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 19:31:44.0392 (UTC) FILETIME=[7B39A080:01C7A93A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3812; t=1181244706; x=1182108706; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20; bh=WT0VG7Araus6uGNC7Ao9qM85Qyz/vz8UbNNGIsZspY8=; b=h4kcNkmNu2146APB+dwlKaNQGsDE7D3KQz3VlrEvCEE1201gj+sCLj3IixF1FSZCT6Ri0YBu AkKYkjrwmkaI5xpoAG8zeTLqn27WRMG9HexSEfI/+QGr5sbMQBWBVYTB; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What do you mean by 'information related to the session usage'? I'll also take this opportunity to remind people of the reasons I think moving forward with more INFO usages is a bad idea: http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt -Jonathan R. Robert Sparks wrote: > I've been getting a lot of offline questions asking for the "right" way > to carry information related to the > session-usage (often information that's being tunneled around from > companion or gatewayed protocols). > > What we've got sitting around right now is probably not enough if we > don't want a new wave of things using INFO. We > need at least an easily findable explanation of why with a pointer to > which other tools would be better considered > for different types of applications. > > RJS > > On Jun 1, 2007, at 3:19 PM, DRAGE, Keith ((Keith)) wrote: > >> (As WG chair) >> >> Is anyone out there interested in pursuing this? >> >> If we did something, it would probably be an update to RFC 3427, and >> I don't see an awful lot of WG resources being consumed if we did, >> i.e. no impact on our existing workload. >> >> However, if we wrote it, would anybody that matters respect it? Does >> it solve any current issues? >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>> Sent: Thursday, May 31, 2007 9:01 PM >>> To: Dean Willis >>> Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings >>> Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >>> >>> Hi, Dean, >>> >>>> However, RFC 2976 is considered to be somewhat >>> >>> underspecified, and so >>> >>>> far the only place we've further specified its usage is in the >>>> context of transporting binary data for telephony protocol >>> >>> tunelling. >>> >>>> We have a standing consensus to NOT use it for arbitrary >>> >>> data at this >>> >>>> time. If we were to start using it, we'd need to do something like >>>> the event-packages model for INFO. So don't use it, and you >>> >>> won't have to deal with this . . >>> >>>> . >>> >>> >>> This is my understanding also, which makes me wonder why >>> http://www.jdrosen.net/papers/draft-rosenberg-sip-info- harmful-00.html >>> didn't advance - I remember the early 00s as a time of >>> frantic IETF movement, so maybe things have settled down >>> enough to confirm the consensus? >>> >>> I am more comfortable if we nail down consensus when we can, >>> rather than pointing people to Jonathan's expired individual >>> draft for support. >>> >>> Other than changing Jonathan's contact information from >>> Dynamicsoft, were there other updates required? :-) >>> >>> Thanks, >>> >>> Spencer >>> >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Jun 07 15:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwO6E-0003za-1s; Thu, 07 Jun 2007 15:56:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwO6C-0003zP-A0 for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 15:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwO6C-0003zH-0Z for sip@ietf.org; Thu, 07 Jun 2007 15:56:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwO6A-000666-I5 for sip@ietf.org; Thu, 07 Jun 2007 15:56:47 -0400 Received: (qmail invoked by alias); 07 Jun 2007 19:56:45 -0000 Received: from p54986919.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.105.25] by mail.gmx.net (mp046) with SMTP; 07 Jun 2007 21:56:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18MSZlUwPAM7fe2LDhs2Ha0viUXOfNKxpvRZTnSvH 7rGF0es0InIIq+ Message-ID: <466862F5.4080202@gmx.net> Date: Thu, 07 Jun 2007 21:56:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: SIP IETF , Cullen Jennings , Keith Drage , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Mary, > Per other responses, there are people that care about this work. But, > unfortunately, it is a bit ahead of the mainstream. However, > I think it > is important and I would hate to see it linger forever in the > WG (it has > already been around for a while). How far is it from being done? We had implementation work going on (to determine whether things work as expected) and investigated different applications in more detail (as published in separate drafts). So, what is missing? We have an issue tracker that contains the open issues: http://www.tschofenig.priv.at:8080/saml-sip/index I will address some (if not all) of them with the next draft update. Planned in about 2 weeks from now. Ciao Hannes > > Mary > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, June 06, 2007 1:37 PM > To: SIP IETF > Cc: Cullen Jennings; Keith Drage > Subject: [Sip] Anybody reading draft-ietf-sip-saml-02.txt > > > > On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > > > 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 SAML Profile and Binding > > Author(s) : H. Tschofenig, et al. > > Filename : draft-ietf-sip-saml-02.txt > > Pages : 46 > > Date : 2007-5-29 > > > So does anybody besides the authors care, or is this work > just so far > ahead of the mainstream working group that we need to move the work > to a lower priority queue? > > > -- > 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 sip-bounces@ietf.org Thu Jun 07 16:29:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwObt-00026E-AO; Thu, 07 Jun 2007 16:29:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwObr-000268-6a for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 16:29:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwObq-00025g-SZ for sip@ietf.org; Thu, 07 Jun 2007 16:29:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwObo-00016N-NQ for sip@ietf.org; Thu, 07 Jun 2007 16:29:30 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 13:29:27 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="161566444:sNHT674968554" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l57KTRuX010919; Thu, 7 Jun 2007 13:29:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57KTM2G023343; Thu, 7 Jun 2007 20:29:27 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:29:26 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:29:25 -0700 Message-ID: <46686AA5.3020607@cisco.com> Date: Thu, 07 Jun 2007 16:29:25 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] GRUU-13 : algorithm in annex A.2 does not distinguish betweenmultiple outbound contacts References: <006901c7899a$06bf7cd0$0601a8c0@BEMBUSTER> <007901c7899c$cb87da10$0601a8c0@BEMBUSTER> In-Reply-To: <007901c7899c$cb87da10$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 20:29:26.0045 (UTC) FILETIME=[8A87F4D0:01C7A942] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3005; t=1181248167; x=1182112167; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20GRUU-13=20=3A=20algorithm=20in=20annex=20A.2= 20does=20not=20distinguish=20betweenmultiple=0A=20outbound=20contacts |Sender:=20; bh=eipVjKPIMvTcdeCRCE9yOdqAmACD1mV2sSeQyFJRetg=; b=jH2Z8Ei6ews4p2vGN1QU+HBlqd6sU3H7jMf2+HYJ0L0zbd7Tg1sW2b368FH/rHpgUQznR0mf qoT+VxxluXzpR2d4FA/KJGqD1Eiq5KwDar9VSDhbXAoibv9X5lUZWGX3; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sorry for the (really) long delay here in responding. Since this UA is, in fact, a single instance, there would only be one public GRUU. When receiving a request targeted to the GRUU, the home proxy would populate the target set with the two contacts bound to the associated instance ID/AOR combo, and then follow regular sip-outbound rules for routing the request. It would not be appropriate to include the reg-id as part of the GRUU. -Jonathan R. Jeroen van Bemmel wrote: > Same remark applies to public GRUU generation: instance-id in 'gr' > parameter may not be sufficient to select the right contact URI for > rewriting, when UAC uses outbound. > > Regards, > Jeroen > > ----- Original Message ----- > *From:* Jeroen van Bemmel > *To:* sip@ietf.org > *Sent:* Saturday, April 28, 2007 3:35 PM > *Subject:* [Sip] GRUU-13 : algorithm in annex A.2 does not > distinguish betweenmultiple outbound contacts > > Jonathan, > > A minor remark about the temporary GRUU algorithm in A.2: if the UAC > is using outbound and registers 2 Contacts under the same AoR and > instance-id, the algorithm in A.2 currently cannot distinguish > between those contacts (since the temporary GRUU only contains an > index which resolves to an AoR+instance combination). Therefore, if > the Contacts URIs are different (for example: different user > part) the proxy is not able to reproduce the correct URI when > rewriting the request URI. > > Concretely: when a UAC registers e.g. > > Contact: > ;+sip.instance="" > ;reg-id=1 > > Contact: > ;+sip.instance="" > ;reg-id=2 > > the proxy returns two distinct temporary GRUUs. However, regardless > of which temporary GRUU the UA chooses to use, the proxy cannot > determine whether to rewrite to "callee-001" or "callee-002" > > This can easily be remedied, e.g. by including the reg-id in the mapping > > Regards, > Jeroen > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Jun 07 16:37:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOjO-0002v0-KT; Thu, 07 Jun 2007 16:37:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwOjM-0002ug-8b for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 16:37:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwOjL-0002uY-VO for sip@ietf.org; Thu, 07 Jun 2007 16:37:15 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwOjL-0002cu-L8 for sip@ietf.org; Thu, 07 Jun 2007 16:37:15 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Jun 2007 13:37:15 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="161570473:sNHT43477083" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l57KbFW6023795; Thu, 7 Jun 2007 13:37:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l57KbEtV017763; Thu, 7 Jun 2007 20:37:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:37:14 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 13:37:13 -0700 Message-ID: <46686C79.8060008@cisco.com> Date: Thu, 07 Jun 2007 16:37:13 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] clarification: multiple outbound registrations and temporary GRUUs: scope of invalidation References: <000f01c78e12$3d8f5e70$0601a8c0@BEMBUSTER> In-Reply-To: <000f01c78e12$3d8f5e70$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 20:37:14.0104 (UTC) FILETIME=[A1841780:01C7A943] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1190; t=1181248635; x=1182112635; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20clarification=3A=20multiple=20outbound=20regi strations=20and=20temporary=0A=20GRUUs=3A=20scope=20of=20invalidation |Sender:=20; bh=oG8mviwHYO1i9t9DH8QT0HlZX4/pUZZ8ck3kmTuW6/Y=; b=pTxFujhoyjbvtCPBTPjwyyPdx93+1+hfsYwEml2OzhxSS+HvXRvDzQWjl9hitAsFHWJIoTAh ds2YtKnKLWPsqeR0c6AlAl0AHirxwEZ1NqRG2Ln84q6DHEZZpp+LKxrg; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org As with my other note, sorry for the very long delay. inline. Jeroen van Bemmel wrote: > All, > > If a UAC performs multiple outbound registrations (reg-id=1 & reg-id=2) > and uses GRUU, the outbound examples show it uses different Call-IDs. > Does that mean that the second registration invalidates the temporary > GRUU returned in the first 200 OK? Based on the GRUU spec, it would. I believe that the UA has to use the same Call-ID for both reg-id. > > In other words: should the temporary GRUU returned for the first Contact > be the same, or different? Well, it should be different no matter what. The registrar is supposed to generate a new temporary GRUU on every register. > > Should outbound recommend to use the same Call-ID for multiple > registrations? (and different from-tags)? Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Jun 07 17:17:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPMf-0004wJ-Jp; Thu, 07 Jun 2007 17:17:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwPMX-0004t1-7U for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 17:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPMW-0004sV-Tj for sip@ietf.org; Thu, 07 Jun 2007 17:17:44 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPJD-0005K4-8w for sip@ietf.org; Thu, 07 Jun 2007 17:14:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l57LEFY08003; Thu, 7 Jun 2007 21:14:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Date: Thu, 7 Jun 2007 16:14:14 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10C66502@zrc2hxm0.corp.nortel.com> In-Reply-To: <46685ABD.7080101@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Thread-Index: AcepORQ113rve+TSQiWe2/BTJ135yQAColOA References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> <46685ABD.7080101@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "Jeroen van Bemmel" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > However to be honest we need to explicitly indicate that the=20 > problem was sips-to-sip so that the original UA can decide=20 > whether to retry. Thus I'd suggest a new 4xx code. I'm fine with this. Let me propose 418 (SIPS Not Allowed) With the following description: The server cannot process the request because the SIPS scheme is not=20 allowed. The UAC SHOULD retry the request, this time, using a SIP URI. This response differs from 416 in that the server recognizes the SIPS URI, but it is not allowed (e.g., because the UAS registered with a SIP Contact header field). (And the current text on proxies not recursing on this will apply) (Note: existing implementations will treat it as 400, which is intended=20 behavior, i.e., it will not automatically re-attempt anything). If you support this, or are against this, please voice your opinion. If you don't=20 care that much, just don't say anything :^) Now, the next logical quesiton is for sip-to-sips. Currently, the text has this text about proxies that may decide to use either 403 or 3XX to redirect to a SIPS URI. We have a similar problem here that some proxy in the middle may decide to recurse on it (which would break the last hop upgrade prohibition). Do we need a 419 (SIPS Required) as well? Or are we happy with the current text? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 17:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPYX-0002zF-Ti; Thu, 07 Jun 2007 17:30:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwPYW-0002vR-EN for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 17:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPYW-0002v8-49 for sip@ietf.org; Thu, 07 Jun 2007 17:30:08 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPYU-00045j-NY for sip@ietf.org; Thu, 07 Jun 2007 17:30:08 -0400 Received: (qmail 3779 invoked by uid 0); 7 Jun 2007 21:29:44 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Jun 2007 21:29:44 -0000 Message-ID: <003401c7a94a$b9bf3b20$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Jonathan Rosenberg" References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> <46685ABD.7080101@cisco.com> Subject: Re: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Date: Thu, 7 Jun 2007 23:28:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan, Yes, that is the text I was refering to. As a consequence of that a proxy MUST NOT recurse on 302 if not responsible for the request URI (but this text is not literally in RFC3261). Still, a 302 sent by the callee's proxy could result in recursion in case of call forwarding scenarios, so conclusion remains that a new 4xx is better Regards, Jeroen Jonathan Rosenberg wrote: > Jeroen van Bemmel wrote: > >> Francois, >> >> Refer to RFC3261 16.5: if a proxy is not responsible for the request >> URI it MUST NOT recurse on 302 > > It most certainly does not say that. > > Perhaps you are referring to this text: > > 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. > > This is referring to the R-URI in the original INVITE, not the one in > the contact in the 3xx. > >> >> 416 does not have the right semantics (since the endpoint may in fact >> support sips, proxies currently should never generate this response) > > WHy is that? Section 21.4.14 says nothing about UA vs. proxies. It > talks about servers. I think 416 is not far off. > > However to be honest we need to explicitly indicate that the problem > was sips-to-sip so that the original UA can decide whether to retry. > Thus I'd suggest a new 4xx code. > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 17:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPcv-0007GT-IR; Thu, 07 Jun 2007 17:34:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwPct-0007GH-HR for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 17:34:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPct-0007G6-7u for sip@ietf.org; Thu, 07 Jun 2007 17:34:39 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPcr-00066m-SE for sip@ietf.org; Thu, 07 Jun 2007 17:34:39 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Jun 2007 14:34:37 -0700 X-IronPort-AV: i="4.16,396,1175497200"; d="scan'208"; a="491658309:sNHT110140974" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l57LYb44021037; Thu, 7 Jun 2007 14:34:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l57LYRaW001277; Thu, 7 Jun 2007 21:34:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:34:31 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 14:34:31 -0700 Message-ID: <466879E6.9010800@cisco.com> Date: Thu, 07 Jun 2007 17:34:30 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jun 2007 21:34:31.0246 (UTC) FILETIME=[A23656E0:01C7A94B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1615; t=1181252077; x=1182116077; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Anybody=20reading=20draft-ietf-sip-saml-02.tx t |Sender:=20; bh=fXGSveeOSkSZoA3EMHoGpnufAZ5q7MGL0q3wUYbBd0s=; b=QaKvoK1r6EnVf3T5Xv6QIovb0wOHprTJd6kajg9xGstl0olIjBR7E5uECotfwP3qzP+2DiS+ 90twit+2f9aY1m3vnIQ76lXn+g4Vp8yng5nyFtZ3QFACGnXmzS4Q7Mxz; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: SIP IETF , Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, given there are still deployments with Remote-Party-ID, who have yet to migrate to P-Asserted-ID, let alone SIP identity, I'd say it is a bit ahead of the curve. That said I do think its worth doing, but is not a high priority. -Jonathan R. Dean Willis wrote: > > On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > >> 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 SAML Profile and Binding >> Author(s) : H. Tschofenig, et al. >> Filename : draft-ietf-sip-saml-02.txt >> Pages : 46 >> Date : 2007-5-29 > > > > So does anybody besides the authors care, or is this work just so far > ahead of the mainstream working group that we need to move the work to > a lower priority queue? > > > -- > 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Thu Jun 07 18:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQBq-0001F0-H4; Thu, 07 Jun 2007 18:10:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwQBp-0001E8-0d for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:10:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQBo-0001Dp-Ls for sip@ietf.org; Thu, 07 Jun 2007 18:10:44 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HwQBo-0005jB-Fc for sip@ietf.org; Thu, 07 Jun 2007 18:10:44 -0400 Received: from [10.31.13.202] (stdhcp-202.va.neustar.com [10.31.13.202]) by ns3.neustar.com (Postfix) with ESMTP id 36123175EA for ; Thu, 7 Jun 2007 22:10:14 +0000 (GMT) Message-ID: <46688247.6020508@neustar.biz> Date: Thu, 07 Jun 2007 15:10:15 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP WG Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> <466879E6.9010800@cisco.com> In-Reply-To: <466879E6.9010800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: IETF SIP WG List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RLBob Morgan buttonholed myself and Keith D. (at least) in hallway in San Diego (I believe) and indicated that they (Internet2 Mace, UWash) want to implement/use the spec and was curious wrt what it would take to "finish" it. That said, as Hannes indicated, we'll endeavor to have another rev out, addressing more of the issues listed in the tracker, sooner rather than later. thanks, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 07 22:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUQX-0005Bz-BQ; Thu, 07 Jun 2007 22:42:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwUQV-0005Bu-VI for sip-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 22:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwUQV-0005Bm-JZ for sip@ietf.org; Thu, 07 Jun 2007 22:42:11 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwUQU-0002ER-9J for sip@ietf.org; Thu, 07 Jun 2007 22:42:11 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l582fQ80020947; Thu, 7 Jun 2007 20:41:26 -0600 Message-ID: <4668C1CC.50909@ntt-at.com> Date: Thu, 07 Jun 2007 19:41:16 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Anybody reading draft-ietf-sip-saml-02.txt References: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> In-Reply-To: <8D8CE9A9-9771-4962-ACC5-740D15393F84@softarmor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIP IETF , Cullen Jennings , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > On May 29, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > >> 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 SAML Profile and Binding >> Author(s) : H. Tschofenig, et al. >> Filename : draft-ietf-sip-saml-02.txt >> Pages : 46 >> Date : 2007-5-29 > > > So does anybody besides the authors care, I care, I think this work is important. > or is this work just so far ahead of the mainstream working group that > we need to move the work to a lower priority queue? I agree as others have mentioned that there are items that are of higher priority(bug fixes etc.), but having followed the draft from its early stage, much effort has gone into the draft and should be in a fairly good shape if issues raised in the last few IETFs are well addressed. If the draft is well baked I see no reason to lower its priority (Assuming the work is nearly done and wouldn't take the resource from more important work that are needed urgently). That being said, it may be good to recruit some reviewers and analyze where the draft is with its maturity and decide its fate. -- Shida > > > -- > 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 sip-bounces@ietf.org Fri Jun 08 01:09:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWil-00011j-8u; Fri, 08 Jun 2007 01:09:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwWij-0000yw-FW for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 01:09:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwWii-0000vN-LJ for sip@ietf.org; Fri, 08 Jun 2007 01:09:08 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwWig-0004M0-QI for sip@ietf.org; Fri, 08 Jun 2007 01:09:08 -0400 Received: from [192.168.2.53] (adsl-67-112-220-125.dsl.sntc01.pacbell.net [67.112.220.125]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l58592CA019769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jun 2007 00:09:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <46685D1F.8040306@cisco.com> References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> <46685D1F.8040306@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 7 Jun 2007 22:08:59 -0700 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 67.112.220.125 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: > What do you mean by 'information related to the session usage'? Ugh - that's what the parenthetical below way trying to talk about. Stuff like digits in INFO (which we say should be done with KPML instead). Stuff like capturing data out of a protocol on the other side of a gateway an tunneling it to either an application or to another gateway. Stuff like data out of the media channel (collected an an IVR perhaps) that needs to be passed to an application server that's not on the media path. More stuff than I think it will be worth trying to build clarity around for this conversation. My point was to _agree_ with what's in sip-info-harmful (you see that Dean also called that out early in the thread) and to note that we don't have the reasoning that's there stated strongly enough in an easy to stumble across place and without that, people are going to continue to find new ways to fill the tubes with INFO requests. (We need _more_ than just what's in your draft - we also need guidance for people who are wanting to do new things with INFO that points them to what we consider sane alternatives instead.) RjS > > I'll also take this opportunity to remind people of the reasons I > think moving forward with more INFO usages is a bad idea: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > -Jonathan R. > > Robert Sparks wrote: > >> I've been getting a lot of offline questions asking for the >> "right" way to carry information related to the >> session-usage (often information that's being tunneled around >> from companion or gatewayed protocols). >> What we've got sitting around right now is probably not enough if >> we don't want a new wave of things using INFO. We >> need at least an easily findable explanation of why with a pointer >> to which other tools would be better considered >> for different types of applications. >> RJS >> On Jun 1, 2007, at 3:19 PM, DRAGE, Keith ((Keith)) wrote: >>> (As WG chair) >>> >>> Is anyone out there interested in pursuing this? >>> >>> If we did something, it would probably be an update to RFC 3427, >>> and I don't see an awful lot of WG resources being consumed if >>> we did, i.e. no impact on our existing workload. >>> >>> However, if we wrote it, would anybody that matters respect it? >>> Does it solve any current issues? >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>>> Sent: Thursday, May 31, 2007 9:01 PM >>>> To: Dean Willis >>>> Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings >>>> Subject: Re: [Sip] INFO message belongs only to INVITE dialog >>>> usage? >>>> >>>> Hi, Dean, >>>> >>>>> However, RFC 2976 is considered to be somewhat >>>> >>>> underspecified, and so >>>> >>>>> far the only place we've further specified its usage is in the >>>>> context of transporting binary data for telephony protocol >>>> >>>> tunelling. >>>> >>>>> We have a standing consensus to NOT use it for arbitrary >>>> >>>> data at this >>>> >>>>> time. If we were to start using it, we'd need to do something like >>>>> the event-packages model for INFO. So don't use it, and you >>>> >>>> won't have to deal with this . . >>>> >>>>> . >>>> >>>> >>>> This is my understanding also, which makes me wonder why >>>> http://www.jdrosen.net/papers/draft-rosenberg-sip-info- >>>> harmful-00.html >>>> didn't advance - I remember the early 00s as a time of >>>> frantic IETF movement, so maybe things have settled down >>>> enough to confirm the consensus? >>>> >>>> I am more comfortable if we nail down consensus when we can, >>>> rather than pointing people to Jonathan's expired individual >>>> draft for support. >>>> >>>> Other than changing Jonathan's contact information from >>>> Dynamicsoft, were there other updates required? :-) >>>> >>>> Thanks, >>>> >>>> Spencer >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.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 sip-bounces@ietf.org Fri Jun 08 01:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwXTP-0003S2-J2; Fri, 08 Jun 2007 01:57:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwXTO-0003P8-0T for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 01:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwXTN-0003Oy-IM for sip@ietf.org; Fri, 08 Jun 2007 01:57:21 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwXTK-00058O-KN for sip@ietf.org; Fri, 08 Jun 2007 01:57:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l585vCT3032463; Fri, 8 Jun 2007 08:57:13 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 08:57:11 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 08:57:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Date: Fri, 8 Jun 2007 08:57:07 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03CADB14@esebe103.NOE.Nokia.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C617EF12@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Thread-Index: AcdjV5vAXxGSnwWIRQ2Zy3wLPXZBURETaYiQAFGd0lAADBOfgAAcqGaQ References: <20070310210143.466231CC77@delta.rtfm.com> <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> <8B1D53AEF7B03449A6D3771B3B7F850F03C807DA@esebe103.NOE.Nokia.com> <9AAEDF491EF7CA48AB587781B8F5D7C617EF12@srvxchg3.cablelabs.com> From: To: X-OriginalArrivalTime: 08 Jun 2007 05:57:08.0647 (UTC) FILETIME=[D96C8B70:01C7A991] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >It would be >helpful to get your feedback on the concept itself, whether you see >challenge/response as the appropriate paradigm, and whether we should >attempt to reuse existing mechanisms such as S/MIME, as there have been >different views on these topics. I haven't built myself any strong opinion on the usefulness of the ability for the UA/user to authenticate by using certificates issued by a CA or the various mechanism how to do that. In overall it seems that in most of the deployments the SIP devices or users do not have PKI certificates for=20 themselves. So the concept seems to apply only to a few specific deployments only (I do not have any idea how big those deployments could be). What comes to the mechanism, I would tend to agree with Eric's analysis: >>primary deficiencies claimed for S/MIME are: >> >>- There is no way for the server to indicate he wants you to >> S/MIME sign. >>- There is no built-in defense against replay attacks. These properties suggest using a challenge-response scheme where the server can decide when to challenge and at that moment give a random nonce for the client to use. I think that reusing existing mechanisms (like S/MIME) makes sense in certain respect to decrease the needed specification effort. However the S/MIME approach is also suffers from a few=20 problems: - S/MIME is not widely implemented for SIP, so there is no great reuse expected for existing implementations. Even the basic (multipart) MIME support is lacking from most of the SIP devices and effort has recently been started in SIP WG to specify how those devices should use MIME bodies. Thus I do not believe S/MIME to be an existing and deployed mechanism for SIP which could be easily reused for this purpose. - Tunneling SIP bodies over S/MIME would easily duplicate the size of the message. This does not only take some bandwidth but would typically force the UA to switch its transport to TCP, which again have some issues for deployments based on UDP (as was discussed in a different thread for SIP Outbound). I have not had a look into this, but perhaps it would be worth for you to investigate: >>Incidentally, I've heard people argue that it would be nice to have a=20 >>generic solution for both HTTP and SIP. This problem has already been=20 >>attacked for HTTP (though with minimal adoption). See S-HTTP (RFC=20 >>2660). Extending the digest authentication framework with new schemes (like for PKI certificates) is not impossible as proven by RFC 3310 for digest AKA, but getting all details right would require the spec to be written very carefully. Regards, Erkki >-----Original Message----- >From: ext Steve Dotson [mailto:S.Dotson@CableLabs.com]=20 >Sent: 07.June.2007 19:02 >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) >Cc: ekr@networkresonance.com; sip@ietf.org >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Thanks Erkki for the thorough review. Responses inline...=20 > >-----Original Message----- >From: Erkki.Koivusalo@nokia.com [mailto:Erkki.Koivusalo@nokia.com]=20 >Sent: Thursday, June 07, 2007 4:47 AM >To: Steve Dotson >Cc: ekr@networkresonance.com; sip@ietf.org >Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 > >Hi Steve, > >I tried to understand how the modified digest algorithm in your draft >works and I have to admit I have difficulties on digesting it. > >First of all your draft tells that the UA should create the >request-digest as follows: > > Once the data string is formed, it MUST be hashed and signed with > private key of the client. The algorithm used for hashing and > signing is specified in the WWW-Authenticate header. > >To verify the received request-digest the server should then do this: > > 6. The server authenticates the client by generating its own > challenge response using the server and client=20 >generated data and > compares its result with that sent in the challenge response by > the client. If the two match, the client has been=20 >authenticated. > >and: > > the server must perform the same cryptographic operation=20 >performed by > the client, and compare the result to the response provided by the > client. > >But how can the server perform the same cryptograpic operation as the >client ? Only the client knows its private key used for creating >request-digest while the server knows only the public key of the user. >The method that you are suggesting would work if there is a shared >secret like in RFC 2617 for HTTP Digest but this is not the case for >using PKI certificates. > >If I have understood it correctly how the digital signatures are used >the process should instead go like this: > >1. The UA creates a hash of the SIP request and the nonce 2. The UA >encrypts the resulting hash with its private key > and sends this digital signature along with the SIP request > >3. The server also creates a hash of the SIP request and the nonce 4. >The server decrypts the encrypted string with the public > key and compares the result to the hash it created in step 3. > >Please tell if you think I have misunderstood any of this. > >[SD] You are correct. This should be clarified. > > >I did not find the draft to describe very clearly how the digital >signing with the private key is performed and which algorithms are used >in different phases of the process. Thus my further questions are >related to the hashing functions introduced in your draft: > > this document, in order to remain consistent with RFC 2617, the > string obtained by applying the algorithm to the data "data" will be > denoted by KD(data)and the string obtained by applying the hash > algorithm to the data "data" will be denoted H(data). > > The algorithm used for hashing and > signing is specified in the WWW-Authenticate header. This document > defines only one "algorithm" value: 'rsa-sha1' > >Does this mean that rsa-sha1 is used for both H(data) and KD(data) ? >If yes, what is then the difference between functions H and KD ? >Or is H(data) supposed to use MD5 instead of rsa-sha1 ?=20 > >Is usage of the private key somehow embedded into your definition of >KD(data) or is signing applied to the hashed string that is received as >a result from KD(data) ? > >[SD] It appears the H(data) is unnecessary, KD could denote the hashing >and encrypting (signing) of the string of data. I was=20 >attempting to work >within the constraints of Digest's current procedures and call flows >while re-using some existing concepts from Identity/AIB/etc.=20 >It would be >helpful to get your feedback on the concept itself, whether you see >challenge/response as the appropriate paradigm, and whether we should >attempt to reuse existing mechanisms such as S/MIME, as there have been >different views on these topics. > >Regards, > >Erkki > >>-----Original Message----- >>From: ext Steve Dotson [mailto:S.Dotson@CableLabs.com] >>Sent: 05.June.2007 22:13 >>To: EKR; sip@ietf.org >>Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 >> >>Eric, thank you for the comments and sorry for the slow response. >> >>As you stated this was a first draft solution based on=20 >>draft-dotson-sip-certificate-auth. We have since updated the=20 >>requirements draft to -03 which can be found at=20 >>http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat >>e-auth-03 >>.txt. >> >>The reasoning behind choosing a challenge/response paradigm=20 >is that is=20 >>the current model used in SIP, and allows a registrar to control when=20 >>and if to authenticate UAs. S/MIME could be a potential mechanism, as=20 >>could Identity or AIB in theory. At a high-level we weren't as=20 >>concerned with the actual mechanism as the signaling and messaging,=20 >>since the signing of some set of data seems to be similar across all=20 >>the current solutions. What we seem to be missing is the=20 >signaling and=20 >>messaging to use certificates for authenticating to a=20 >registrar/network > >>or another UA. Without challenge/response, the UA would=20 >always need to=20 >>do cryptographic processing and messages are larger, whether=20 >or not the > >>other end is requiring authentication. For UA to UA=20 >authentication, the > >>issue is even more of a concern, as we don't want UAs assuming=20 >>authentication of every dialog request. >> >>Is it a fair statement that S/MIME/AIB/Identity all use similar=20 >>cryptographic tools but vary in the specific data from the dialog=20 >>chosen to sign? >> >>Is there any preference to which "mechanism" is used for the solution? >> >>Do all the solutions have issues with middleboxes? >> >>Thanks. >> >>Steve. >>=20 >> >>-----Original Message----- >>From: EKR [mailto:ekr@networkresonance.com] >>Sent: Saturday, March 10, 2007 2:02 PM >>To: sip@ietf.org >>Subject: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 >> >>$Id: draft-dotson-sip-certificate-auth-sol-00-rev.txt,v 1.1=20 >2007/03/10=20 >>21:13:10 ekr Exp $ >> >>The native SIP authentication scheme is Digest authentication. This=20 >>draft and its companion draft-dotson-sip-certificate-auth=20 >argue that it > >>is desirable to have an authentication scheme based on public key=20 >>certificates that can span multiple hops (TLS client auth lets you=20 >>authenticate to the first hop proxy). To some extent, SIP already has=20 >>such a scheme: messages can be S/MIME signed. As I understand it, the=20 >>primary deficiencies claimed for S/MIME are: >> >>- There is no way for the server to indicate he wants you to >> S/MIME sign. >>- There is no built-in defense against replay attacks. >> >>In order to correct this situation, this draft proposes an=20 >extension to > >>HTTP Digest to add a signature mode. I'm not sure how important this=20 >>problem actually is, but I'm skeptical that this draft is the=20 >best way=20 >>to go about it. >> >>It seems to me that this proposal confuses two issues: >> >>1. The formatting of the signature over the data. >>2. How the server indicates that it wants a signature. >> >>This proposal addresses both, but its solution to (1) is clumsy and=20 >>replicates functionality we already have, namely S/MIME. >>It's fine to define a new form of authentication challenge that says=20 >>"please sign with your S/MIME cert" and even have it include a nonce,=20 >>but there's no need to model the response on Digest auth. >>You can simply include the challenge in the material you sign over. >> >>Incidentally, I've heard people argue that it would be nice to have a=20 >>generic solution for both HTTP and SIP. This problem has already been=20 >>attacked for HTTP (though with minimal adoption). See S-HTTP (RFC=20 >>2660). >> >>-Ekr >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use=20 >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>sipping@ietf.org for new developments on the application of sip >> >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use=20 >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 02:10:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwXfe-0003Qn-0Q; Fri, 08 Jun 2007 02:10:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwXfb-00033e-PZ for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 02:09:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwXfb-000326-DN for sip@ietf.org; Fri, 08 Jun 2007 02:09:59 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwXfZ-0008KB-VH for sip@ietf.org; Fri, 08 Jun 2007 02:09:59 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5869lmw011429; Fri, 8 Jun 2007 09:09:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:09:52 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 09:09:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Date: Fri, 8 Jun 2007 09:09:50 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03CADB31@esebe103.NOE.Nokia.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C617EF12@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Review of draft-dotson-sip-certificate-auth-sol-00 Thread-Index: AcdjV5vAXxGSnwWIRQ2Zy3wLPXZBURETaYiQAFGd0lAADBOfgAAdg3YA References: <20070310210143.466231CC77@delta.rtfm.com> <9AAEDF491EF7CA48AB587781B8F5D7C617ECA6@srvxchg3.cablelabs.com> <8B1D53AEF7B03449A6D3771B3B7F850F03C807DA@esebe103.NOE.Nokia.com> <9AAEDF491EF7CA48AB587781B8F5D7C617EF12@srvxchg3.cablelabs.com> From: To: X-OriginalArrivalTime: 08 Jun 2007 06:09:51.0759 (UTC) FILETIME=[A04631F0:01C7A993] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Steve, One more thing for you to think just in case you=20 will continue with your effort of extending the digest framework for this: >Is usage of the private key somehow embedded into your definition of >KD(data) or is signing applied to the hashed string that is received as >a result from KD(data) ? > >[SD] It appears the H(data) is unnecessary, KD could denote the hashing >and encrypting (signing) of the string of data. I believe that you have to separate the steps of (a) hashing and (b) encrypting the hash like suggested in my comment: >the process should instead go like this: > >1. The UA creates a hash of the SIP request and the nonce=20 >2. The UA encrypts the resulting hash with its private key > and sends this digital signature along with the SIP request > >3. The server also creates a hash of the SIP request and the nonce=20 >4. The server decrypts the encrypted string with the public > key and compares the result to the hash it created in step 3. Thus you probably need to define two functions: a) One for creating the hash from the SIP request. This=20 function does not use any secret or public key. Most probably the parts of the request to be hashed are as specified in AIB RFC 3893. b) Another for creating the digital signature over the hash. This function takes as its input the hash from the previous step and the private key related to user's certificate. These two functions could use different hash functions, so you have to specify both. P.S. Please do not believe me to be an experienced security expert, I am just in process of learning cryptography by myself. Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 03:49:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZDX-0001ZM-Ib; Fri, 08 Jun 2007 03:49:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwZDV-0001Ok-Mt for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 03:49:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZDV-0001Mc-B1 for sip@ietf.org; Fri, 08 Jun 2007 03:49:05 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZDT-0007So-R3 for sip@ietf.org; Fri, 08 Jun 2007 03:49:05 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l587mwxx017758 for ; Fri, 8 Jun 2007 10:49:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:48:52 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:48:52 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:48:52 +0300 Received: from [172.21.40.106] (esdhcp040106.research.nokia.com [172.21.40.106]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l587mo45032220 for ; Fri, 8 Jun 2007 10:48:50 +0300 Message-ID: <466909E3.6040709@nokia.com> Date: Fri, 08 Jun 2007 10:48:51 +0300 From: Aki Niemi User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 07:48:52.0252 (UTC) FILETIME=[75157DC0:01C7A9A1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] Open issue in subnot etags X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All, There is a single open issue in http://tools.ietf.org/id/draft-ietf-sip-subnot-etags-00.txt It relates to handling of list subscriptions. Specifically, what approach should we take in defining how conditional notification works in RLSs? Seems there are roughly four different approaches: 1. Treat meta-information as independent of the actual resource state, don't apply conditional notification to meta-information at all. 2. Treat everything as a single resource, and update the etag whenever either meta or real info changes. 3. Have separate etags for meta and real information. 4. Ignore the issue. If we think this is an issue this draft should address, then my preference would be to option #2. Otherwise, #4 would be the easiest given this issue is really specific to one event type only, and can be solved separately if needed. Opinions? If I don't hear anything from anyone, I guess I'll have to flip a coin to determine between #2 and #4. ;-) Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 05:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwaKG-0005S0-9O; Fri, 08 Jun 2007 05:00:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwaKE-0005Fc-2l for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 05:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwaKC-0005C1-7A; Fri, 08 Jun 2007 05:00:04 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwaKB-00074H-Es; Fri, 08 Jun 2007 05:00:04 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9D89220C7F; Fri, 8 Jun 2007 10:59:58 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-51-46691a8e6b33 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7D62520B8E; Fri, 8 Jun 2007 10:59:58 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:59:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Jun 2007 11:00:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contradiction in RC 3515 - SIP REFER Method Thread-Index: Acepq2Vqt09CU6N7Ti+mA/2n4P5w/w== From: "Ian Elz (CV/ETL)" To: , X-OriginalArrivalTime: 08 Jun 2007 08:59:58.0153 (UTC) FILETIME=[63C25390:01C7A9AB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Subject: [Sip] Contradiction in RC 3515 - SIP REFER Method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0101771958==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0101771958== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9AB.63A3EA04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9AB.63A3EA04 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been looking at RFC3515 and have found the following: Section 2.2 contains the table of headers supported in the REFER method and contains the following: Header Where REFER ... Expires R o Section 2.4.4 "Using SIP Events to Report the Results of the Reference" contains the following paragraph: Notice that unlike SUBSCRIBE, the REFER transaction does not contain a duration for the subscription in either the request or the response. The lifetime of the state being subscribed to is determined by the progress of the referenced request. The duration of the subscription is chosen by the agent accepting the REFER and is communicated to the agent sending the REFER in the subscription's initial NOTIFY (using the Subscription-State expires header parameter). Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY. Which part of the RFC is correct ? What happens if a REFER does contain an Expires header ?=20 Should the Expire duration included in the REFER be used in preference to the time which would be allocated by the agent receiving the REFER as described in 2.4.4 ? If the Expire duration is "0" is this equivalent to using the Refer-sub header being set to false ?=20 Ian Elz Office: + 44 24 764 35256 gsm: +44 7801723668 ian.elz@ericsson.com ------_=_NextPart_001_01C7A9AB.63A3EA04 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Contradiction in RC 3515 - SIP REFER Method

I have been looking at RFC3515 and have = found the following:

Section 2.2 contains the table of = headers supported in the REFER method and contains the following:

      = Header           &= nbsp;        Where   = REFER
      = …
      = Expires           =           = R       o

Section 2.4.4 "Using SIP Events to = Report the Results of the Reference" contains the following = paragraph:

   Notice that unlike = SUBSCRIBE, the REFER transaction does not contain
   a duration for the = subscription in either the request or the
   response.  The = lifetime of the state being subscribed to is
   determined by the = progress of the referenced request.  The duration
   of the subscription = is chosen by the agent accepting the REFER and is
   communicated to the = agent sending the REFER in the subscription's
   initial NOTIFY = (using the Subscription-State expires header
   parameter).  = Note that agents accepting REFER and not wishing to hold
   subscription state = can terminate the subscription with this initial
   NOTIFY.

Which part of the RFC is correct = ?

What happens if a REFER does contain an = Expires header ?

Should the Expire duration included in = the REFER be used in preference to the time which would be allocated by = the agent receiving the REFER as described in 2.4.4 ?

If the Expire duration is "0" = is this equivalent to using the Refer-sub header being set to false ? =


Ian Elz

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz@ericsson.com


------_=_NextPart_001_01C7A9AB.63A3EA04-- --===============0101771958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0101771958==-- From sip-bounces@ietf.org Fri Jun 08 05:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwb9Q-0004A6-N0; Fri, 08 Jun 2007 05:53:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwb9N-00047A-98 for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 05:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwb9M-00046q-KS; Fri, 08 Jun 2007 05:52:56 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwb9L-0006nm-Uj; Fri, 08 Jun 2007 05:52:56 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 08 Jun 2007 02:52:55 -0700 X-IronPort-AV: i="4.16,399,1175497200"; d="scan'208,217"; a="15788216:sNHT104513468" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 10:52:53 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Contradiction in RC 3515 - SIP REFER Method Date: Fri, 8 Jun 2007 10:52:50 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097E76A@EMAILEMEA3.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Contradiction in RC 3515 - SIP REFER Method Thread-Index: Acepq2Vqt09CU6N7Ti+mA/2n4P5w/wABiKrw References: From: "Gilad Shaham" To: "Ian Elz \(CV/ETL\)" X-OriginalArrivalTime: 08 Jun 2007 09:52:53.0724 (UTC) FILETIME=[C88C01C0:01C7A9B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: sip@ietf.org, sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1079545327==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1079545327== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9B2.C881D3A8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9B2.C881D3A8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Ian, =20 Here is something, a bit old, but might hint an answer: http://www1.ietf.org/mail-archive/web/sip/current/msg01917.html =20 Based on that and section 2.4.4, I would say that the intent was to give no meaning to Expires in REFER. Section 2.2 might be something no one noticed until now. =20 Gilad =20 ________________________________ From: Ian Elz (CV/ETL) [mailto:ian.elz@ericsson.com]=20 Sent: Friday, June 08, 2007 12:00 PM To: sip@ietf.org; sipping@ietf.org Subject: [Sip] Contradiction in RC 3515 - SIP REFER Method =20 I have been looking at RFC3515 and have found the following:=20 Section 2.2 contains the table of headers supported in the REFER method and contains the following:=20 Header Where REFER=20 ...=20 Expires R o=20 Section 2.4.4 "Using SIP Events to Report the Results of the Reference" contains the following paragraph:=20 Notice that unlike SUBSCRIBE, the REFER transaction does not contain=20 a duration for the subscription in either the request or the=20 response. The lifetime of the state being subscribed to is=20 determined by the progress of the referenced request. The duration=20 of the subscription is chosen by the agent accepting the REFER and is communicated to the agent sending the REFER in the subscription's=20 initial NOTIFY (using the Subscription-State expires header=20 parameter). Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial=20 NOTIFY.=20 Which part of the RFC is correct ?=20 What happens if a REFER does contain an Expires header ?=20 Should the Expire duration included in the REFER be used in preference to the time which would be allocated by the agent receiving the REFER as described in 2.4.4 ? If the Expire duration is "0" is this equivalent to using the Refer-sub header being set to false ?=20 =20 Ian Elz=20 Office: + 44 24 764 35256=20 gsm: +44 7801723668=20 ian.elz@ericsson.com=20 =20 ------_=_NextPart_001_01C7A9B2.C881D3A8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Contradiction in RC 3515 - SIP REFER Method

Hi = Ian,

 

Here is something, a bit old, but = might hint an answer:

= http://www1.ietf.org/mail-archive/web/sip/current/msg01917.html<= /o:p>

 

Based on that and section 2.4.4, I = would say that the intent was to give no meaning to Expires in REFER. Section = 2.2 might be something no one noticed until = now.

 

Gilad

 

From: Ian = Elz (CV/ETL) [mailto:ian.elz@ericsson.com]
Sent: Friday, June 08, = 2007 12:00 PM
To: sip@ietf.org; = sipping@ietf.org
Subject: [Sip] = Contradiction in RC 3515 - SIP REFER Method

 

I have been looking at RFC3515 and have found the following: =

Section 2.2 contains the table of headers supported in the REFER method and = contains the following:

      Header           &= nbsp;        Where   REFER
      …
      Expires           =           R       o

Section 2.4.4 "Using SIP Events to Report the Results of the = Reference" contains the following paragraph:

   Notice that unlike SUBSCRIBE, the REFER = transaction does not contain
   a duration for the subscription in either the request or = the
   response.  The lifetime of the state being subscribed to = is
   determined by the progress of the referenced request.  The = duration
   of the subscription is chosen by the agent accepting the REFER and = is
   communicated to the agent sending the REFER in the = subscription's
   initial NOTIFY (using the Subscription-State expires = header
   parameter).  Note that agents accepting REFER and not wishing to = hold
   subscription state can terminate the subscription with this = initial
   NOTIFY.

Which part of the RFC is correct ?

What happens if a REFER does contain an Expires header ? =

Should the Expire duration included in the REFER be used in preference to the = time which would be allocated by the agent receiving the REFER as described = in 2.4.4 ?

If the Expire duration is "0" is this equivalent to using the = Refer-sub header being set to false ?

 

Ian Elz

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz@ericsson.com =

 

------_=_NextPart_001_01C7A9B2.C881D3A8-- --===============1079545327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1079545327==-- From sip-bounces@ietf.org Fri Jun 08 07:36:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwclc-0000dq-QH; Fri, 08 Jun 2007 07:36:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwclb-0000dg-EZ for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 07:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwclb-0000dY-55 for sip@ietf.org; Fri, 08 Jun 2007 07:36:31 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwclZ-0007qv-Rp for sip@ietf.org; Fri, 08 Jun 2007 07:36:31 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JJB004NPEWSNI@usaga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jun 2007 04:36:29 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJB005EFEWRTP@usaga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jun 2007 04:36:28 -0700 (PDT) Date: Fri, 08 Jun 2007 06:34:21 -0500 From: Spencer Dawkins Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? To: Robert Sparks , Jonathan Rosenberg Message-id: <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> <46685D1F.8040306@cisco.com> <403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Robert/Jonathan, > On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: > >> What do you mean by 'information related to the session usage'? > > Ugh - that's what the parenthetical below way trying to talk about. > Stuff like digits in INFO (which we say should be done with KPML > instead). > Stuff like capturing data out of a protocol on the other side of a > gateway an tunneling it to > either an application or to another gateway. > Stuff like data out of the media channel (collected an an IVR perhaps) > that needs to be passed > to an application server that's not on the media path. > More stuff than I think it will be worth trying to build clarity around > for this conversation. > > My point was to _agree_ with what's in sip-info-harmful (you see that > Dean also called that out early in the thread) > and to note that we don't have the reasoning that's there stated strongly > enough in an easy to stumble across place > and without that, people are going to continue to find new ways to fill > the tubes with INFO requests. Two separate issues, both important... > (We need _more_ than just what's in your draft - we also need Jonathan may remember that I asked about his draft in discussions about the hitchhiker's guide. The answsr was, of course, that we didn't have a reasonable reference to the draft, so couldn't tell people who were trying to learn about SIP "don't go there" (until, of course, they "go there" and submit draft-newbie-sip-whatever-over-info-00). So at the very least, we need an RFC number that's not in the draft now! > guidance for people who are wanting to do new > things with INFO that points them to what we consider sane alternatives > instead.) It would be OK with me if we ALSO had this type of guidance ("don't look HERE, look over THERE") available ("stated strongly enough in an easy to stumble across place"), but if coming up with that guidance takes more than about a week, I don't see a lot of reason to hold up on "don't go there" while we explore alternatives. If we don't progress stuff like this, we can't be surprised when the experts spend all their time explaining the same stuff over and over again, onlist. New participants don't want to repeat old bad ideas. They have plenty of opportunities to come up with NEW bad ideas. This is a SIP community responsibility, not just Jonathan's and not just the chairs' responsibility. Jonathan did his part (in 2003), and Dean points to this draft about once a month. We need to find a way to move past lather-rinse-repeat about long-time semi-documented consensus. IMO. Of course. > RjS > >> >> I'll also take this opportunity to remind people of the reasons I think >> moving forward with more INFO usages is a bad idea: >> >> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 07:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwcrb-0003vI-Hi; Fri, 08 Jun 2007 07:42:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwcrZ-0003qw-MZ for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 07:42:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcrZ-0003px-C2 for sip@ietf.org; Fri, 08 Jun 2007 07:42:41 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcrX-0000xY-Kg for sip@ietf.org; Fri, 08 Jun 2007 07:42:41 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FC36213E5; Fri, 8 Jun 2007 13:42:36 +0200 (CEST) X-AuditID: c1b4fb3e-af9eebb0000061ca-e2-466940ab32f6 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D015B2175B; Fri, 8 Jun 2007 13:42:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 13:42:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 13:42:34 +0200 Message-ID: <7374777208BDC7449D5620EF9423256704F5F473@esealmw113.eemea.ericsson.se> In-Reply-To: <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskg References: <465E9331.8070909@zesium.com><095901c7a3be$7ace6990$6801a8c0@china.huawei.com><5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com><20049800-688B-43DE-B001-23CB527C807E@nostrum.com><46685D1F.8040306@cisco.com><403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> From: "Christer Holmberg (JO/LMF)" To: "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 08 Jun 2007 11:42:35.0341 (UTC) FILETIME=[1B7F0FD0:01C7A9C2] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, People are implementing INFO usages WITHOUT submitting = draft-newbie-sip-whatever-over-info-00. And, when looking at which companies are doing it, it can be discussed = whether all of them can be considered being "SIP newbies"... But, that's = another issue. Regards, Christer =20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: 8. kes=E4kuuta 2007 14:34 > To: Robert Sparks; Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > Hi, Robert/Jonathan, >=20 > > On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: > > > >> What do you mean by 'information related to the session usage'? > > > > Ugh - that's what the parenthetical below way trying to talk about. > > Stuff like digits in INFO (which we say should be done with KPML=20 > > instead). > > Stuff like capturing data out of a protocol on the other side of a=20 > > gateway an tunneling it to either an application or to another=20 > > gateway. > > Stuff like data out of the media channel (collected an an IVR =20 > > perhaps) that needs to be passed to an application server=20 > that's not=20 > > on the media path. > > More stuff than I think it will be worth trying to build clarity =20 > > around for this conversation. > > > > My point was to _agree_ with what's in sip-info-harmful=20 > (you see that=20 > > Dean also called that out early in the thread) and to note that we=20 > > don't have the reasoning that's there stated strongly enough in an=20 > > easy to stumble across place and without that, people are going to=20 > > continue to find new ways to fill the tubes with INFO requests. >=20 > Two separate issues, both important... >=20 > > (We need _more_ than just what's in your draft - we also need >=20 > Jonathan may remember that I asked about his draft in=20 > discussions about the hitchhiker's guide. The answsr was, of=20 > course, that we didn't have a reasonable reference to the=20 > draft, so couldn't tell people who were trying to learn about=20 > SIP "don't go there" (until, of course, they "go there" and=20 > submit draft-newbie-sip-whatever-over-info-00). >=20 > So at the very least, we need an RFC number that's not in the=20 > draft now! >=20 > > guidance for people who are wanting to do new things with INFO that=20 > > points them to what we consider sane alternatives > > instead.) >=20 > It would be OK with me if we ALSO had this type of guidance=20 > ("don't look HERE, look over THERE") available ("stated=20 > strongly enough in an easy to stumble across place"), but if=20 > coming up with that guidance takes more than about a week, I=20 > don't see a lot of reason to hold up on "don't go there"=20 > while we explore alternatives. >=20 > If we don't progress stuff like this, we can't be=20 > surprised when the experts spend all their time explaining=20 > the same stuff over and over again, onlist. New participants=20 > don't want to repeat old bad ideas. They have plenty of=20 > opportunities to come up with NEW bad ideas. This is a SIP=20 > community responsibility, not just Jonathan's and not just=20 > the chairs'=20 > responsibility. Jonathan did his part (in 2003), and Dean=20 > points to this draft about once a month. We need to find a=20 > way to move past lather-rinse-repeat about long-time=20 > semi-documented consensus. >=20 > IMO. Of course. >=20 > >=20 > > RjS > > > >> > >> I'll also take this opportunity to remind people of the reasons I =20 > >> think moving forward with more INFO usages is a bad idea: > >> > >>=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 07:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcxG-000151-8l; Fri, 08 Jun 2007 07:48:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwcxE-0000tv-9H for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 07:48:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwcxD-0000tn-Vl for sip@ietf.org; Fri, 08 Jun 2007 07:48:31 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwcxC-0002Px-EB for sip@ietf.org; Fri, 08 Jun 2007 07:48:31 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l58BmTwE025342 for ; Fri, 8 Jun 2007 11:48:29 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l58BmTEa4141152 for ; Fri, 8 Jun 2007 13:48:29 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l58BmTPX002549 for ; Fri, 8 Jun 2007 13:48:29 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l58BmT4A002546; Fri, 8 Jun 2007 13:48:29 +0200 In-Reply-To: <466909E3.6040709@nokia.com> To: Aki Niemi Subject: Re: [Sip] Open issue in subnot etags MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Avshalom Houri Message-ID: Date: Fri, 8 Jun 2007 14:48:27 +0300 X-MIMETrack: Serialize by Router on D12ML102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 08/06/2007 14:48:28, Serialize complete at 08/06/2007 14:48:28 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1138938162==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1138938162== Content-Type: multipart/alternative; boundary="=_alternative 0040DB1CC22572F4_=" This is a multipart message in MIME format. --=_alternative 0040DB1CC22572F4_= Content-Type: text/plain; charset="US-ASCII" I think that we should address the issue. Either 2 or 3 will be good but 2 will be much more simpler. --Avshalom Aki Niemi 08/06/2007 10:48 To sip@ietf.org cc Subject [Sip] Open issue in subnot etags All, There is a single open issue in http://tools.ietf.org/id/draft-ietf-sip-subnot-etags-00.txt It relates to handling of list subscriptions. Specifically, what approach should we take in defining how conditional notification works in RLSs? Seems there are roughly four different approaches: 1. Treat meta-information as independent of the actual resource state, don't apply conditional notification to meta-information at all. 2. Treat everything as a single resource, and update the etag whenever either meta or real info changes. 3. Have separate etags for meta and real information. 4. Ignore the issue. If we think this is an issue this draft should address, then my preference would be to option #2. Otherwise, #4 would be the easiest given this issue is really specific to one event type only, and can be solved separately if needed. Opinions? If I don't hear anything from anyone, I guess I'll have to flip a coin to determine between #2 and #4. ;-) Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0040DB1CC22572F4_= Content-Type: text/html; charset="US-ASCII"
I think that we should address the issue. Either 2 or 3 will be good
but 2 will be much more simpler.

--Avshalom


Aki Niemi <aki.niemi@nokia.com>

08/06/2007 10:48

To
sip@ietf.org
cc
Subject
[Sip] Open issue in subnot etags





All,

There is a single open issue in
http://tools.ietf.org/id/draft-ietf-sip-subnot-etags-00.txt

It relates to handling of list subscriptions. Specifically, what
approach should we take in defining how conditional notification works
in RLSs?  Seems there are roughly four different approaches:

   1.  Treat meta-information as independent of the actual resource
       state, don't apply conditional notification to meta-information
       at all.

   2.  Treat everything as a single resource, and update the etag
       whenever either meta or real info changes.

   3.  Have separate etags for meta and real information.

   4.  Ignore the issue.

If we think this is an issue this draft should address, then my
preference would be to option #2. Otherwise, #4 would be the easiest
given this issue is really specific to one event type only, and can be
solved separately if needed.

Opinions?

If I don't hear anything from anyone, I guess I'll have to flip a coin
to determine between #2 and #4. ;-)

Cheers,
Aki



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--=_alternative 0040DB1CC22572F4_=-- --===============1138938162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1138938162==-- From sip-bounces@ietf.org Fri Jun 08 08:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwdtj-0003ZA-HQ; Fri, 08 Jun 2007 08:48:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwdth-0003Z0-SW for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 08:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwdth-0003Ys-J0 for sip@ietf.org; Fri, 08 Jun 2007 08:48:57 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwdtf-0003EC-Qd for sip@ietf.org; Fri, 08 Jun 2007 08:48:57 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1Hwdtc-00088M-9z; Fri, 08 Jun 2007 05:48:52 -0700 Content-class: urn:content-classes:message Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 05:48:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C31772A@sea02-mxc01.citel.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <7374777208BDC7449D5620EF9423256704F5F473@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZA= References: <465E9331.8070909@zesium.com><095901c7a3be$7ace6990$6801a8c0@china.huawei.com><5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com><20049800-688B-43DE-B001-23CB527C807E@nostrum.com><46685D1F.8040306@cisco.com><403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com><048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> <7374777208BDC7449D5620EF9423256704F5F473@esealmw113.eemea.ericsson.se> From: "Steve Langstaff" To: "Christer Holmberg \(JO/LMF\)" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Maybe "sip-info-harmful" should be the first "WCP" (Worst Current = Practice) document? =20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 08 June 2007 12:43 > To: Spencer Dawkins; Robert Sparks; Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi, >=20 > People are implementing INFO usages WITHOUT submitting=20 > draft-newbie-sip-whatever-over-info-00. >=20 > And, when looking at which companies are doing it, it can be=20 > discussed whether all of them can be considered being "SIP=20 > newbies"... But, that's another issue. >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > Sent: 8. kes=E4kuuta 2007 14:34 > > To: Robert Sparks; Jonathan Rosenberg > > Cc: sip@ietf.org > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > > Hi, Robert/Jonathan, > >=20 > > > On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: > > > > > >> What do you mean by 'information related to the session usage'? > > > > > > Ugh - that's what the parenthetical below way trying to=20 > talk about. > > > Stuff like digits in INFO (which we say should be done with KPML=20 > > > instead). > > > Stuff like capturing data out of a protocol on the other=20 > side of a=20 > > > gateway an tunneling it to either an application or to another=20 > > > gateway. > > > Stuff like data out of the media channel (collected an an IVR > > > perhaps) that needs to be passed to an application server > > that's not > > > on the media path. > > > More stuff than I think it will be worth trying to build clarity=20 > > > around for this conversation. > > > > > > My point was to _agree_ with what's in sip-info-harmful > > (you see that > > > Dean also called that out early in the thread) and to=20 > note that we=20 > > > don't have the reasoning that's there stated strongly=20 > enough in an=20 > > > easy to stumble across place and without that, people are=20 > going to=20 > > > continue to find new ways to fill the tubes with INFO requests. > >=20 > > Two separate issues, both important... > >=20 > > > (We need _more_ than just what's in your draft - we also need > >=20 > > Jonathan may remember that I asked about his draft in discussions=20 > > about the hitchhiker's guide. The answsr was, of course, that we=20 > > didn't have a reasonable reference to the draft, so couldn't tell=20 > > people who were trying to learn about SIP "don't go there"=20 > (until, of=20 > > course, they "go there" and submit=20 > > draft-newbie-sip-whatever-over-info-00). > >=20 > > So at the very least, we need an RFC number that's not in the draft=20 > > now! > >=20 > > > guidance for people who are wanting to do new things with=20 > INFO that=20 > > > points them to what we consider sane alternatives > > > instead.) > >=20 > > It would be OK with me if we ALSO had this type of guidance ("don't=20 > > look HERE, look over THERE") available ("stated strongly=20 > enough in an=20 > > easy to stumble across place"), but if coming up with that guidance=20 > > takes more than about a week, I don't see a lot of reason=20 > to hold up=20 > > on "don't go there" > > while we explore alternatives. > >=20 > > If we don't progress stuff like this, we can't be=20 > surprised when=20 > > the experts spend all their time explaining the same stuff over and=20 > > over again, onlist. New participants don't want to repeat old bad=20 > > ideas. They have plenty of opportunities to come up with NEW bad=20 > > ideas. This is a SIP community responsibility, not just=20 > Jonathan's and=20 > > not just the chairs' > > responsibility. Jonathan did his part (in 2003), and Dean points to=20 > > this draft about once a month. We need to find a way to move past=20 > > lather-rinse-repeat about long-time semi-documented consensus. > >=20 > > IMO. Of course. > >=20 > > > >=20 > > > RjS > > > > > >> > > >> I'll also take this opportunity to remind people of the=20 > reasons I=20 > > >> think moving forward with more INFO usages is a bad idea: > > >> > > >>=20 > >=20 > http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 09:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hweq6-0005JY-Jz; Fri, 08 Jun 2007 09:49:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hweq5-0005B4-3O for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 09:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hweq4-00058i-Nb; Fri, 08 Jun 2007 09:49:16 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hweq0-0000EC-MR; Fri, 08 Jun 2007 09:49:16 -0400 Received: from [192.168.2.53] (adsl-67-112-220-125.dsl.sntc01.pacbell.net [67.112.220.125]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l58Dn8fk045511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jun 2007 08:49:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0E48B768805E4D44A70709C8AE09209097E76A@EMAILEMEA3.jnpr.net> References: <0E48B768805E4D44A70709C8AE09209097E76A@EMAILEMEA3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Robert Sparks Subject: Re: [Sipping] RE: [Sip] Contradiction in RC 3515 - SIP REFER Method Date: Fri, 8 Jun 2007 06:48:46 -0700 To: "Gilad Shaham" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 67.112.220.125 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: sip@ietf.org, "Ian Elz \(CV/ETL\)" , sipping@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1636710576==" Errors-To: sip-bounces@ietf.org --===============1636710576== Content-Type: multipart/alternative; boundary=Apple-Mail-1--1007620137 --Apple-Mail-1--1007620137 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed And what I said in the message Gilad points to still holds. RjS On Jun 8, 2007, at 2:52 AM, Gilad Shaham wrote: > Hi Ian, > > > > Here is something, a bit old, but might hint an answer: > > http://www1.ietf.org/mail-archive/web/sip/current/msg01917.html > > > > Based on that and section 2.4.4, I would say that the intent was to =20= > give no meaning to Expires in REFER. Section 2.2 might be something =20= > no one noticed until now. > > > > Gilad > > > > From: Ian Elz (CV/ETL) [mailto:ian.elz@ericsson.com] > Sent: Friday, June 08, 2007 12:00 PM > To: sip@ietf.org; sipping@ietf.org > Subject: [Sip] Contradiction in RC 3515 - SIP REFER Method > > > > I have been looking at RFC3515 and have found the following: > > Section 2.2 contains the table of headers supported in the REFER =20 > method and contains the following: > > Header Where REFER > =85 > Expires R o > > Section 2.4.4 "Using SIP Events to Report the Results of the =20 > Reference" contains the following paragraph: > > Notice that unlike SUBSCRIBE, the REFER transaction does not =20 > contain > a duration for the subscription in either the request or the > response. The lifetime of the state being subscribed to is > determined by the progress of the referenced request. The duration > of the subscription is chosen by the agent accepting the REFER =20 > and is > communicated to the agent sending the REFER in the subscription's > initial NOTIFY (using the Subscription-State expires header > parameter). Note that agents accepting REFER and not wishing to =20= > hold > subscription state can terminate the subscription with this initial > NOTIFY. > > Which part of the RFC is correct ? > > What happens if a REFER does contain an Expires header ? > > Should the Expire duration included in the REFER be used in =20 > preference to the time which would be allocated by the agent =20 > receiving the REFER as described in 2.4.4 ? > > If the Expire duration is "0" is this equivalent to using the Refer-=20= > sub header being set to false ? > > > > Ian Elz > > Office: + 44 24 764 35256 > gsm: +44 7801723668 > ian.elz@ericsson.com > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP --Apple-Mail-1--1007620137 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 And what I said in the message = Gilad points to still holds.

RjS

On Jun 8, 2007, = at 2:52 AM, Gilad Shaham wrote:

Hi = Ian,

=A0

Here is = something, a bit old, but might hint an = answer:

h= ttp://www1.ietf.org/mail-archive/web/sip/current/msg01917.html

=A0

Based on that = and section 2.4.4, I would say that the intent was to give no meaning to = Expires in REFER. Section 2.2 might be something no one noticed until = now.

=A0

Gilad

=A0

=

From: Ian Elz (CV/ETL) [mailto:ian.elz@ericsson.com] =
Sent: Friday, June = 08, 2007 12:00 PM
To: = sip@ietf.org; sipping@ietf.org
Subject: [Sip] Contradiction in RC = 3515 - SIP REFER Method

=A0

I have been looking at = RFC3515 and have found the following: =

Section 2.2 contains the = table of headers supported in the REFER method and contains the = following:

=A0=A0=A0=A0=A0 Header=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 Where=A0=A0 REFER
=A0=A0=A0=A0= =A0 =85
=A0=A0=A0=A0= =A0 Expires=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = R=A0=A0=A0=A0=A0=A0 o

Section = 2.4.4 "Using SIP Events to Report the Results of the Reference" contains = the following paragraph:

=A0=A0 Notice that unlike SUBSCRIBE, the REFER = transaction does not contain
=A0=A0 a duration for the subscription in either = the request or the
=A0=A0 response.=A0 The lifetime of the state being = subscribed to is
=A0=A0 determined by the progress of the referenced request.=A0= The duration
=A0=A0 of the subscription is chosen by the agent accepting = the REFER and is
=A0=A0 communicated to the agent sending the REFER in the = subscription's
=A0=A0 initial NOTIFY (using the Subscription-State expires = header
=A0=A0 = parameter).=A0 Note that agents accepting REFER and not wishing to = hold
=A0=A0 = subscription state can terminate the subscription with this = initial
=A0=A0 = NOTIFY.

Which = part of the RFC is correct ?

What happens if a REFER = does contain an Expires header ?

Should the Expire duration = included in the REFER be used in preference to the time which would be = allocated by the agent receiving the REFER as described in 2.4.4 = ?

If the Expire duration is = "0" is this equivalent to using the Refer-sub header being set to false = ?

=A0

Ian Elz

Office: = + 44 24 764 35256
gsm: +44 7801723668
ian.elz@ericsson.com

=A0

This list is = for NEW development of the application of SIP
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sip@ietf.org for new developments of = core SIP

= --Apple-Mail-1--1007620137-- --===============1636710576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1636710576==-- From sip-bounces@ietf.org Fri Jun 08 09:54:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwevN-0000OS-Pq; Fri, 08 Jun 2007 09:54:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwevL-0000OL-0k for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 09:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwevK-0000OD-Na for sip@ietf.org; Fri, 08 Jun 2007 09:54:42 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwevK-0003Ib-Co for sip@ietf.org; Fri, 08 Jun 2007 09:54:42 -0400 Received: from [192.168.2.53] (adsl-67-112-220-125.dsl.sntc01.pacbell.net [67.112.220.125]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l58DseqC045775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Jun 2007 08:54:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> <46685D1F.8040306@cisco.com> <403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 06:54:38 -0700 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 67.112.220.125 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Spencer - I can't tell if you thought I was saying to hold moving info-harmful forward until we had better answers or not - I wasn't. I'm saying we aren't done just by moving it forward. It will help on its own, but we'll have to get to the guidance part quickly for it to really help much. RjS On Jun 8, 2007, at 4:34 AM, Spencer Dawkins wrote: > Hi, Robert/Jonathan, > >> On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: >> >>> What do you mean by 'information related to the session usage'? >> >> Ugh - that's what the parenthetical below way trying to talk about. >> Stuff like digits in INFO (which we say should be done with KPML >> instead). >> Stuff like capturing data out of a protocol on the other side of a >> gateway an tunneling it to >> either an application or to another gateway. >> Stuff like data out of the media channel (collected an an IVR >> perhaps) that needs to be passed >> to an application server that's not on the media path. >> More stuff than I think it will be worth trying to build clarity >> around for this conversation. >> >> My point was to _agree_ with what's in sip-info-harmful (you see >> that Dean also called that out early in the thread) >> and to note that we don't have the reasoning that's there stated >> strongly enough in an easy to stumble across place >> and without that, people are going to continue to find new ways >> to fill the tubes with INFO requests. > > Two separate issues, both important... > >> (We need _more_ than just what's in your draft - we also need > > Jonathan may remember that I asked about his draft in discussions > about the hitchhiker's guide. The answsr was, of course, that we > didn't have a reasonable reference to the draft, so couldn't tell > people who were trying to learn about SIP "don't go there" (until, > of course, they "go there" and submit draft-newbie-sip-whatever- > over-info-00). > > So at the very least, we need an RFC number that's not in the draft > now! > >> guidance for people who are wanting to do new >> things with INFO that points them to what we consider sane >> alternatives instead.) > > It would be OK with me if we ALSO had this type of guidance ("don't > look HERE, look over THERE") available ("stated strongly enough in > an easy to stumble across place"), but if coming up with that > guidance takes more than about a week, I don't see a lot of reason > to hold up on "don't go there" while we explore alternatives. > > If we don't progress stuff like this, we can't be surprised > when the experts spend all their time explaining the same stuff > over and over again, onlist. New participants don't want to repeat > old bad ideas. They have plenty of opportunities to come up with > NEW bad ideas. This is a SIP community responsibility, not just > Jonathan's and not just the chairs' responsibility. Jonathan did > his part (in 2003), and Dean points to this draft about once a > month. We need to find a way to move past lather-rinse-repeat about > long-time semi-documented consensus. > > IMO. Of course. > > > >> RjS >> >>> >>> I'll also take this opportunity to remind people of the reasons >>> I think moving forward with more INFO usages is a bad idea: >>> >>> http://www.jdrosen.net/papers/draft-rosenberg-sip-info- >>> harmful-00.txt > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 10:06:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwf6r-00059r-QW; Fri, 08 Jun 2007 10:06:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwf6p-00059i-E2 for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 10:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwf6p-00059a-4S for sip@ietf.org; Fri, 08 Jun 2007 10:06:35 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwf6m-00009i-Hb for sip@ietf.org; Fri, 08 Jun 2007 10:06:35 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 08 Jun 2007 07:06:22 -0700 X-IronPort-AV: i="4.16,400,1175497200"; d="scan'208"; a="15894595:sNHT24327533224" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Jun 2007 15:04:28 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 15:04:24 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011C31772A@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYA== References: <465E9331.8070909@zesium.com><095901c7a3be$7ace6990$6801a8c0@china.huawei.com><5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com><20049800-688B-43DE-B001-23CB527C807E@nostrum.com><46685D1F.8040306@cisco.com><403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com><048401c7a9c0$f55a2890$6801a8c0@china.huawei.com><7374777208BDC7449D5620EF9423256704F5F473@esealmw113.eemea.ericsson.se> <0D4E483A0E6E0A46861409E5D6C2011C31772A@sea02-mxc01.citel.com> From: "Gilad Shaham" To: "Steve Langstaff" , "Christer Holmberg \(JO/LMF\)" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 08 Jun 2007 14:04:28.0421 (UTC) FILETIME=[EDAFFB50:01C7A9D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Many people are still under the impression that DTMF should/can be done = with INFO. For example: http://www.vonage-forum.com/ftopic5305.html I'm not even sure how many people are aware of RFC 4730 as it's quite = new. However, RFC 4730 does not explain why DTMF should be done by event = notification rather than INFO. This feature was missing for a long time = in SIP so many implementations already have INFO with DTMF (I won't = provide links for that, but it's easy to find via any popular search = engine). I also seem to remember a company, with a lot of experience with SIP = that offered a few years ago to do floor control with INFO. Basically = anyone who wants to do something proprietary without thinking about it = too much will go for INFO. Since RFC 3265 came out things have improved = because many realize event packages are a better solution. However, INFO = is still considered a viable candidate for many of these solutions = because it seems as an option SIP provides and perhaps even endorses. I = assume it's because the INFO concept is very simple. Unfortunately INFO is required for SIP-T, therefore there is a valid = usage. The options I see are: 1. Provide BCP (or WCP as stated below) for INFO. 2. Deprecate the current RFC and define INFO for SIP-T only. 3. Find another solution for SIP-T and wipe out INFO from SIP. 4. Find more cases that mandate INFO (are there any?) and redefine its = scope. Gilad > -----Original Message----- > From: Steve Langstaff [mailto:steve.langstaff@citel.com] > Sent: Friday, June 08, 2007 3:49 PM > To: Christer Holmberg (JO/LMF); Spencer Dawkins; Robert Sparks; = Jonathan > Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > Maybe "sip-info-harmful" should be the first "WCP" (Worst Current > Practice) document? >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 08 June 2007 12:43 > > To: Spencer Dawkins; Robert Sparks; Jonathan Rosenberg > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > > > > Hi, > > > > People are implementing INFO usages WITHOUT submitting > > draft-newbie-sip-whatever-over-info-00. > > > > And, when looking at which companies are doing it, it can be > > discussed whether all of them can be considered being "SIP > > newbies"... But, that's another issue. > > > > Regards, > > > > Christer > > > > > > > > > > > -----Original Message----- > > > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > > Sent: 8. kes=E4kuuta 2007 14:34 > > > To: Robert Sparks; Jonathan Rosenberg > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog = usage? > > > > > > Hi, Robert/Jonathan, > > > > > > > On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: > > > > > > > >> What do you mean by 'information related to the session usage'? > > > > > > > > Ugh - that's what the parenthetical below way trying to > > talk about. > > > > Stuff like digits in INFO (which we say should be done with KPML > > > > instead). > > > > Stuff like capturing data out of a protocol on the other > > side of a > > > > gateway an tunneling it to either an application or to another > > > > gateway. > > > > Stuff like data out of the media channel (collected an an IVR > > > > perhaps) that needs to be passed to an application server > > > that's not > > > > on the media path. > > > > More stuff than I think it will be worth trying to build clarity > > > > around for this conversation. > > > > > > > > My point was to _agree_ with what's in sip-info-harmful > > > (you see that > > > > Dean also called that out early in the thread) and to > > note that we > > > > don't have the reasoning that's there stated strongly > > enough in an > > > > easy to stumble across place and without that, people are > > going to > > > > continue to find new ways to fill the tubes with INFO requests. > > > > > > Two separate issues, both important... > > > > > > > (We need _more_ than just what's in your draft - we also need > > > > > > Jonathan may remember that I asked about his draft in discussions > > > about the hitchhiker's guide. The answsr was, of course, that we > > > didn't have a reasonable reference to the draft, so couldn't tell > > > people who were trying to learn about SIP "don't go there" > > (until, of > > > course, they "go there" and submit > > > draft-newbie-sip-whatever-over-info-00). > > > > > > So at the very least, we need an RFC number that's not in the = draft > > > now! > > > > > > > guidance for people who are wanting to do new things with > > INFO that > > > > points them to what we consider sane alternatives > > > > instead.) > > > > > > It would be OK with me if we ALSO had this type of guidance = ("don't > > > look HERE, look over THERE") available ("stated strongly > > enough in an > > > easy to stumble across place"), but if coming up with that = guidance > > > takes more than about a week, I don't see a lot of reason > > to hold up > > > on "don't go there" > > > while we explore alternatives. > > > > > > If we don't progress stuff like this, we can't be > > surprised when > > > the experts spend all their time explaining the same stuff over = and > > > over again, onlist. New participants don't want to repeat old bad > > > ideas. They have plenty of opportunities to come up with NEW bad > > > ideas. This is a SIP community responsibility, not just > > Jonathan's and > > > not just the chairs' > > > responsibility. Jonathan did his part (in 2003), and Dean points = to > > > this draft about once a month. We need to find a way to move past > > > lather-rinse-repeat about long-time semi-documented consensus. > > > > > > IMO. Of course. > > > > > > > > > > > > > RjS > > > > > > > >> > > > >> I'll also take this opportunity to remind people of the > > reasons I > > > >> think moving forward with more INFO usages is a bad idea: > > > >> > > > >> > > > > > = http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 10:17:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfHC-0004d9-0X; Fri, 08 Jun 2007 10:17:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwfHA-0004Zv-Vl for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 10:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfHA-0004Zd-LN for sip@ietf.org; Fri, 08 Jun 2007 10:17:16 -0400 Received: from mvimap.mailvision.net ([212.143.248.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfH7-0006xg-D9 for sip@ietf.org; Fri, 08 Jun 2007 10:17:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id B7B71768E64; Fri, 8 Jun 2007 16:14:51 +0300 (IDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvhQhU3YcYMP; Fri, 8 Jun 2007 16:14:46 +0300 (IDT) Received: from diego-besprosvans-mac-mini.local (diegob.bb.netvision.net.il [212.143.127.193]) by mvimap.mailvision.net (Postfix) with ESMTP id 17B36768E65; Fri, 8 Jun 2007 16:14:46 +0300 (IDT) Message-ID: <466962FC.4030908@mailvision.com> Date: Fri, 08 Jun 2007 17:09:00 +0300 From: Diego B User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Gilad Shaham Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <465E9331.8070909@zesium.com><095901c7a3be$7ace6990$6801a8c0@china.huawei.com><5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com><20049800-688B-43DE-B001-23CB527C807E@nostrum.com><46685D1F.8040306@cisco.com><403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com><048401c7a9c0$f55a2890$6801a8c0@china.huawei.com><7374777208BDC7449D5620EF9423256704F5F473@esealmw113.eemea.ericsson.se> <0D4E483A0E6E0A46861409E5D6C2011C31772A@sea02-mxc01.citel.com> <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi; Don't forget that most Media Servers Control protocols use SIP info to carry their XML payload to control the media server. Regards Diego B Gilad Shaham wrote: > Many people are still under the impression that DTMF should/can be done= with INFO. > For example: http://www.vonage-forum.com/ftopic5305.html > I'm not even sure how many people are aware of RFC 4730 as it's quite n= ew. However, RFC 4730 does not explain why DTMF should be done by event n= otification rather than INFO. This feature was missing for a long time in= SIP so many implementations already have INFO with DTMF (I won't provide= links for that, but it's easy to find via any popular search engine). > > I also seem to remember a company, with a lot of experience with SIP th= at offered a few years ago to do floor control with INFO. Basically anyon= e who wants to do something proprietary without thinking about it too muc= h will go for INFO. Since RFC 3265 came out things have improved because = many realize event packages are a better solution. However, INFO is still= considered a viable candidate for many of these solutions because it see= ms as an option SIP provides and perhaps even endorses. I assume it's bec= ause the INFO concept is very simple. > > Unfortunately INFO is required for SIP-T, therefore there is a valid us= age. > > The options I see are: > 1. Provide BCP (or WCP as stated below) for INFO. > 2. Deprecate the current RFC and define INFO for SIP-T only. > 3. Find another solution for SIP-T and wipe out INFO from SIP. > 4. Find more cases that mandate INFO (are there any?) and redefine its = scope. > > > Gilad > > =20 >> -----Original Message----- >> From: Steve Langstaff [mailto:steve.langstaff@citel.com] >> Sent: Friday, June 08, 2007 3:49 PM >> To: Christer Holmberg (JO/LMF); Spencer Dawkins; Robert Sparks; Jonath= an >> Rosenberg >> Cc: sip@ietf.org >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >> >> Maybe "sip-info-harmful" should be the first "WCP" (Worst Current >> Practice) document? >> >> =20 >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: 08 June 2007 12:43 >>> To: Spencer Dawkins; Robert Sparks; Jonathan Rosenberg >>> Cc: sip@ietf.org >>> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >>> >>> >>> Hi, >>> >>> People are implementing INFO usages WITHOUT submitting >>> draft-newbie-sip-whatever-over-info-00. >>> >>> And, when looking at which companies are doing it, it can be >>> discussed whether all of them can be considered being "SIP >>> newbies"... But, that's another issue. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> =20 >>>> -----Original Message----- >>>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>>> Sent: 8. kes=E4kuuta 2007 14:34 >>>> To: Robert Sparks; Jonathan Rosenberg >>>> Cc: sip@ietf.org >>>> Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >>>> >>>> Hi, Robert/Jonathan, >>>> >>>> =20 >>>>> On Jun 7, 2007, at 12:31 PM, Jonathan Rosenberg wrote: >>>>> >>>>> =20 >>>>>> What do you mean by 'information related to the session usage'? >>>>>> =20 >>>>> Ugh - that's what the parenthetical below way trying to >>>>> =20 >>> talk about. >>> =20 >>>>> Stuff like digits in INFO (which we say should be done with KPML >>>>> instead). >>>>> Stuff like capturing data out of a protocol on the other >>>>> =20 >>> side of a >>> =20 >>>>> gateway an tunneling it to either an application or to another >>>>> gateway. >>>>> Stuff like data out of the media channel (collected an an IVR >>>>> perhaps) that needs to be passed to an application server >>>>> =20 >>>> that's not >>>> =20 >>>>> on the media path. >>>>> More stuff than I think it will be worth trying to build clarity >>>>> around for this conversation. >>>>> >>>>> My point was to _agree_ with what's in sip-info-harmful >>>>> =20 >>>> (you see that >>>> =20 >>>>> Dean also called that out early in the thread) and to >>>>> =20 >>> note that we >>> =20 >>>>> don't have the reasoning that's there stated strongly >>>>> =20 >>> enough in an >>> =20 >>>>> easy to stumble across place and without that, people are >>>>> =20 >>> going to >>> =20 >>>>> continue to find new ways to fill the tubes with INFO requests. >>>>> =20 >>>> Two separate issues, both important... >>>> >>>> =20 >>>>> (We need _more_ than just what's in your draft - we also need >>>>> =20 >>>> Jonathan may remember that I asked about his draft in discussions >>>> about the hitchhiker's guide. The answsr was, of course, that we >>>> didn't have a reasonable reference to the draft, so couldn't tell >>>> people who were trying to learn about SIP "don't go there" >>>> =20 >>> (until, of >>> =20 >>>> course, they "go there" and submit >>>> draft-newbie-sip-whatever-over-info-00). >>>> >>>> So at the very least, we need an RFC number that's not in the draft >>>> now! >>>> >>>> =20 >>>>> guidance for people who are wanting to do new things with >>>>> =20 >>> INFO that >>> =20 >>>>> points them to what we consider sane alternatives >>>>> instead.) >>>>> =20 >>>> It would be OK with me if we ALSO had this type of guidance ("don't >>>> look HERE, look over THERE") available ("stated strongly >>>> =20 >>> enough in an >>> =20 >>>> easy to stumble across place"), but if coming up with that guidance >>>> takes more than about a week, I don't see a lot of reason >>>> =20 >>> to hold up >>> =20 >>>> on "don't go there" >>>> while we explore alternatives. >>>> >>>> If we don't progress stuff like this, we can't be >>>> =20 >>> surprised when >>> =20 >>>> the experts spend all their time explaining the same stuff over and >>>> over again, onlist. New participants don't want to repeat old bad >>>> ideas. They have plenty of opportunities to come up with NEW bad >>>> ideas. This is a SIP community responsibility, not just >>>> =20 >>> Jonathan's and >>> =20 >>>> not just the chairs' >>>> responsibility. Jonathan did his part (in 2003), and Dean points to >>>> this draft about once a month. We need to find a way to move past >>>> lather-rinse-repeat about long-time semi-documented consensus. >>>> >>>> IMO. Of course. >>>> >>>> >>>> >>>> =20 >>>>> RjS >>>>> >>>>> =20 >>>>>> I'll also take this opportunity to remind people of the >>>>>> =20 >>> reasons I >>> =20 >>>>>> think moving forward with more INFO usages is a bad idea: >>>>>> >>>>>> >>>>>> =20 >>> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt >>> =20 >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>>> =20 >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >>> =20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> =20 > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 12:55:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwhjd-0000Hy-25; Fri, 08 Jun 2007 12:54:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwhjc-0000Gn-9w for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 12:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwhjc-0000Gf-0I for sip@ietf.org; Fri, 08 Jun 2007 12:54:48 -0400 Received: from smtpauth03.prod.mesa1.secureserver.net ([64.202.165.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwhjb-0002BL-94 for sip@ietf.org; Fri, 08 Jun 2007 12:54:47 -0400 Received: (qmail 22080 invoked from network); 8 Jun 2007 16:54:46 -0000 Received: from unknown (85.52.255.203) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 08 Jun 2007 16:54:44 -0000 Message-ID: <466989D1.9010803@genaker.net> Date: Fri, 08 Jun 2007 18:54:41 +0200 From: David Viamonte User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Sip] Open issue in subnot etags References: In-Reply-To: X-Spam-Score: 1.4 (+) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: sip@ietf.org, Aki Niemi X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1178119166==" Errors-To: sip-bounces@ietf.org --===============1178119166== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just my 2c...

I agree with Avshalom. IMMO, including the subscription to Presence lists case (provided that this does not add too much overhead, and the solution remains consistent) would lead to a more complete specification.

I also like 2 and 3, and I agree 2 is simpler.

Hope it helps.

Regards,

David


Avshalom Houri escribió:

I think that we should address the issue. Either 2 or 3 will be good
but 2 will be much more simpler.

--Avshalom


Aki Niemi <aki.niemi@nokia.com>

08/06/2007 10:48

To
 sip@ietf.org
cc
Subject
 [Sip] Open issue in subnot etags







All,

There is a single open issue in
http://tools.ietf.org/id/draft-ietf-sip-subnot-etags-00.txt

It relates to handling of list subscriptions. Specifically, what
approach should we take in defining how conditional notification works
in RLSs?  Seems there are roughly four different approaches:

   1.  Treat meta-information as independent of the actual resource
       state, don't apply conditional notification to meta-information
       at all.

   2.  Treat everything as a single resource, and update the etag
       whenever either meta or real info changes.

   3.  Have separate etags for meta and real information.

   4.  Ignore the issue.

If we think this is an issue this draft should address, then my
preference would be to option #2. Otherwise, #4 would be the easiest
given this issue is really specific to one event type only, and can be
solved separately if needed.

Opinions?

If I don't hear anything from anyone, I guess I'll have to flip a coin
to determine between #2 and #4. ;-)

Cheers,
Aki



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip
--===============1178119166== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1178119166==-- From sip-bounces@ietf.org Fri Jun 08 16:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwl6l-0001xk-0D; Fri, 08 Jun 2007 16:30:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwl6i-0001sy-98 for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 16:30:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwl6h-0001sT-I2 for sip@ietf.org; Fri, 08 Jun 2007 16:30:51 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwl6f-0004FM-Lr for sip@ietf.org; Fri, 08 Jun 2007 16:30:50 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l58KUlr17506; Fri, 8 Jun 2007 20:30:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 15:30:45 -0500 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC Review: draft-ietf-sip-session-policy-framework-01 thread-index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxgOF18Aw From: "Mary Barnes" To: "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: draft-ietf-sip-session-policy-framework@tools.ietf.org Subject: [Sip] WGLC Review: draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-session-policy-framework-01 Reviewer: Mary Barnes Review Date: 8 June 2007 Review Deadline: 11 June 2007 Status: WGLC Summary: This draft is basically ready for publication, but has nits=20 that should be fixed before publication.=20 Comments: ---------- I reviewed the diff for this document as compared to the version=20 I previously reviewed: http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-si pping-session-policy-framework-01-barnes.txt And, I believe all my previous concerns have been addressed. There are a=20 few nits that I noticed that should be fixed. Nits: ------ - Header: Need to add "Intended Status:" (i.e., category=3D"std" in the field)=20 - Section 4.4.1: - 2nd paragraph, 5th sentence: insert "the" between "using" and "mechanism" in the following sentence: "If the UAC decides to continue, it MUST use the policy server=20 URI to contact the policy server using the mechanism defined in=20 Section 4.5." - 2nd paragraph, 8th sentence: "resend" -> "resent" in the following sentence: "If no changes are required by policies or no policies have been received, the request can be resend without any policy-induced changes." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 17:36:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwm7i-00033O-Sz; Fri, 08 Jun 2007 17:35:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwm7i-00033C-3b for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 17:35:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwm7h-000334-QM for sip@ietf.org; Fri, 08 Jun 2007 17:35:57 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwm7h-0008Lh-GI for sip@ietf.org; Fri, 08 Jun 2007 17:35:57 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JJC00J796NW5Y@usaga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jun 2007 14:35:56 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJC00BKM6NU0P@usaga01-in.huawei.com> for sip@ietf.org; Fri, 08 Jun 2007 14:35:56 -0700 (PDT) Date: Fri, 08 Jun 2007 16:33:56 -0500 From: Spencer Dawkins Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? To: Robert Sparks Message-id: <069001c7aa14$b85933b0$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> <46685D1F.8040306@cisco.com> <403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Robert, > Spencer - I can't tell if you thought I was saying to hold moving > info-harmful forward until > we had better answers or not - I wasn't. My bad. It wasn't obvious to me from your otherwise-excellent note whether you were thinking of two separate documents. I just wanted to make sure we would do something soon (at least measured in IETF years). Given that saying "don't go there" has taken four years since Jonathan's last update, I was concerned that saying "don't look here, look over there" would take more time than I was willing to spend continuing to point to an expired draft. I have pointed this out previously in private e-mail, but http://www.ietf.org/internet-drafts/draft-melanchuk-mediactrl-framework-00.txt is having to put forward its own analysis of "why not INFO" in Section 5 ("SIP Usage"), because Tim doesn't have anything we can refer to except an expired individual draft. I'd rather rely on a document done here than text in the MEDIACTRL framework document, just because I think the larger SIP community would look at text done here more closely than in a MEDIACTRL draft. IMO, of course. > I'm saying we aren't done just by moving it forward. Ack. > It will help on its own, but we'll have to get to the guidance part > quickly for it to really help much. Double Ack. > RjS Thanks for clarifying (so that I'm now clear :-). Spencer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 18:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnJl-0005Ek-AJ; Fri, 08 Jun 2007 18:52:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwnJj-0005DH-H9 for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 18:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwnJj-0005Cd-6Q for sip@ietf.org; Fri, 08 Jun 2007 18:52:27 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwnJh-0007IF-Vc for sip@ietf.org; Fri, 08 Jun 2007 18:52:27 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l58MqNh07468 for ; Fri, 8 Jun 2007 22:52:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Jun 2007 17:52:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10CB7B87@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for transport=tls Thread-Index: AceoBuBZq8yBp0IvQ5ysE7QxNkeanwAcDYiAAFs52TA= References: <9EB2A6FF-1BF3-4CA2-9728-CE2B4F52FA3A@softarmor.com> <860C1B4D-2EFA-4ACF-946A-92781A4E9FA0@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD3A3@zrc2hxm0.corp.nortel.com> <2C36413C-A703-4821-A5A5-A9A48330EE30@nostrum.com> <1ECE0EB50388174790F9694F77522CCF10BBD5FA@zrc2hxm0.corp.nortel.com> <18020.27378.227115.453498@tutpro.com> <46665999.6090900@softarmor.com> <1ECE0EB50388174790F9694F77522CCF10C656EB@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "SIP IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Sip] Proposal for transport=tls X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Based on the feedback from the mailing list from the last few days,=20 I'm proposing the following: - That we do not re-instate "transport=3Dtls" at this point (i.e., in=20 the draft-ietf-sip-sips draft). - As suggested by Paul Kyzivat, we would defer any work on = transport=3Dtls to later. As such, we would add this topic in Annex A "Future Steps in Specification". We would describe the uses cases that are currently not covered by this draft: URIs that need to specify TLS as a transport, as per the Redirect server and Location server examples that were described by Robert Sparks. =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 08 20:44:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwp40-0006Er-0P; Fri, 08 Jun 2007 20:44:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hwp3x-0005yd-Lx for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 20:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwp3x-0005uZ-8B for sip@ietf.org; Fri, 08 Jun 2007 20:44:17 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwp3v-0003NF-Qo for sip@ietf.org; Fri, 08 Jun 2007 20:44:17 -0400 Received: from 206-176-144-212.waymark.net ([206.176.144.212]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hwp6S-0006fc-53; Fri, 08 Jun 2007 19:46:52 -0500 In-Reply-To: <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> References: <465E9331.8070909@zesium.com> <095901c7a3be$7ace6990$6801a8c0@china.huawei.com> <5D1A7985295922448D5550C94DE291800124C40D@DEEXC1U01.de.lucent.com> <20049800-688B-43DE-B001-23CB527C807E@nostrum.com> <46685D1F.8040306@cisco.com> <403C611A-8285-41BB-B739-0E2DA89FDDEC@nostrum.com> <048401c7a9c0$f55a2890$6801a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61C6570D-1F40-470F-8B35-AAFE921EE26B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 19:44:01 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 8, 2007, at 6:34 AM, Spencer Dawkins wrote: > > Two separate issues, both important... > >> (We need _more_ than just what's in your draft - we also need > > Jonathan may remember that I asked about his draft in discussions > about the hitchhiker's guide. The answsr was, of course, that we > didn't have a reasonable reference to the draft, so couldn't tell > people who were trying to learn about SIP "don't go there" (until, > of course, they "go there" and submit draft-newbie-sip-whatever- > over-info-00). > > So at the very least, we need an RFC number that's not in the draft > now! > >> guidance for people who are wanting to do new >> things with INFO that points them to what we consider sane >> alternatives instead.) > > It would be OK with me if we ALSO had this type of guidance ("don't > look HERE, look over THERE") available ("stated strongly enough in > an easy to stumble across place"), but if coming up with that > guidance takes more than about a week, I don't see a lot of reason > to hold up on "don't go there" while we explore alternatives. > > If we don't progress stuff like this, we can't be surprised > when the experts spend all their time explaining the same stuff > over and over again, onlist. New participants don't want to repeat > old bad ideas. They have plenty of opportunities to come up with > NEW bad ideas. This is a SIP community responsibility, not just > Jonathan's and not just the chairs' responsibility. Jonathan did > his part (in 2003), and Dean points to this draft about once a > month. We need to find a way to move past lather-rinse-repeat about > long-time semi-documented consensus. > > IMO. Of course. > > Schrodinger's cat is out of the bag and off eating mice somewhere. SIP is a transport protocol. INFO is its freight carrier. People have used it and will use it in ways that make us queasy. The only thing to do is to produce some guidelines about documenting those "ways" and provide both registration and peer-negotiation for "ways" so that we don't have a meltdown. Much like we did for event packages. -- 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 sip-bounces@ietf.org Mon Jun 11 09:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjmo-0006XO-9S; Mon, 11 Jun 2007 09:18:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hxjmm-0006XG-Oj for sip-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 09:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxjmm-0006X7-F1 for sip@ietf.org; Mon, 11 Jun 2007 09:18:20 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxjml-0006Nu-2i for sip@ietf.org; Mon, 11 Jun 2007 09:18:20 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l5BDIEVQ012205 for ; Mon, 11 Jun 2007 08:18:18 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 08:17:57 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 15:17:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Date: Mon, 11 Jun 2007 15:17:52 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800128BE84@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxgQNnWaw References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "DRAGE, Keith \(Keith\)" , "IETF SIP List" X-OriginalArrivalTime: 11 Jun 2007 13:17:55.0236 (UTC) FILETIME=[EC0F0640:01C7AC2A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A further reminder that we would like comments on this WGLC by the end of today. If you have comments, the please submit them. If you are likely to read this document then now would be a good time to complete that review. Keith=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Monday, May 21, 2007 11:06 PM > To: IETF SIP List > Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 >=20 > (As WG chair) >=20 > This is to announce a Working Group Last Call on >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-pol > icy-framew > ork-01.txt >=20 > The WGLC is for 3 weeks and will end on 11th June 2007. >=20 > Please respond to the editor, and to the SIP mailing list=20 > with comments. >=20 > This WGLC is being held in conjunction with the two related=20 > documents in the SIPPING group, see mail below: >=20 > Regards >=20 > Keith >=20 > -------------------------------------------------------------- > ---------- > ----------------------------- >=20 > Hi all, >=20 > This is to announce Working Group Last Call on the following=20 > documents: > http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-p > olicy-data > set-04.txt (Recently updated to address the merging issue=20 > discussed on the mailing list) > http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy- > package-03 > .txt (Unchanged since prior to IETF-68) >=20 > This WGLC will end on 11 June 2007. >=20 > Since the WG has previously reviewed these documents, the=20 > plan is to keep the same set of reviewers that previously=20 > volunteered:=20 > Bob Penfield, Shida Schubert, Flemming Andreasen, Roni=20 > Even However, anyone additional that would like to volunteer=20 > would be appreciated to get a fresh set of eyes on the document.=20 >=20 > Feedback should be sent to the authors' email addresses=20 > (which is cc'ed using the tools alias in the above for your=20 > convenience) and please copy the SIPPING mailing list. =20 >=20 > Note: the original plan was to WGLC this set of documents=20 > along with the framework document that moved to SIP. So,=20 > stay tuned for an announcement on the SIP list of the WGLC=20 > plans for that document.=20 >=20 > Thanks, > Mary > SIPPING WG co-chair >=20 > -------------------------------------------------------------- > ---------- > ------------------------------- >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 11 19:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtbD-0008DY-Nt; Mon, 11 Jun 2007 19:47:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HxtbB-0008DP-Rm for sip-confirm+ok@megatron.ietf.org; Mon, 11 Jun 2007 19:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxtbB-0008DH-I0 for sip@ietf.org; Mon, 11 Jun 2007 19:47:01 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxtb9-0000nY-G9 for sip@ietf.org; Mon, 11 Jun 2007 19:47:01 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hxtdn-00062u-Vp for sip@ietf.org; Mon, 11 Jun 2007 18:49:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9EF8005D-D890-430A-AB2F-990D5A780DF7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Mon, 11 Jun 2007 18:46:41 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] Agenda for Chicago X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'll be assembling the draft agenda for our meetings in Chicago, so please send me requests for time on the agenda. Note that we'll be first assigning time to chartered items that we're behind on, then to chartered items in general, then to stuff we've been talking about that's likely to be chartered or affect chartered work, and only after that to new work. Since I don't expect to have a lot of time left over for new work, if you want agenda time, please make sure you have "critical mass" on- list before asking for meeting time. It'll keep me from having to say "no", which I always hate doing. Further, please try and keep our valuable face-to-face time for dealing with contentious, complicated, controversial (or other things requiring face-to-face discussion) issues, and do the easy stuff "on list". Thanks, -- Dean SIP co-Chair du jour, pro tem, ad-hoc, and wistfully emeritus. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 05:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2UE-0000Iz-8H; Tue, 12 Jun 2007 05:16:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy2UD-0000It-6y for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 05:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2UC-0000Il-QE for sip@ietf.org; Tue, 12 Jun 2007 05:16:24 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy2UC-0000Mp-F7 for sip@ietf.org; Tue, 12 Jun 2007 05:16:24 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5C9EOq0015902 for ; Tue, 12 Jun 2007 04:16:19 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 04:15:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 11:13:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2007 11:13:47 +0200 Message-ID: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-saml-02 Thread-Index: Aces0fucrfmQnBbDRJiKX5ZPB1I70Q== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 12 Jun 2007 09:13:48.0828 (UTC) FILETIME=[FC8845C0:01C7ACD1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Sip] draft-ietf-sip-saml-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) Well it seems there is interest in this work, but it is not getting the attention it deserves. =20 Some people also seem to think it is almost there, but we have no way of judging that without seeing the what comments are being made against the document (or of course reviewing it ourselves). This week is a quiet week (we supposedly finished our current WGLC yesterday, and we are not yet ready to initiate another one, and the draft closured deadlines for the forthcoming IETF are still a little bit away). =20 We therefore task the working group to take the next 7 calendar days (ending Monday 18th June) to open up: http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt And for everyone to post at least one comment on the document to the SIP list. Posts can cover any of: - completeness - is there something missing? - applicability - does it identify and solve a problem? - readability - I didn't understand what it was trying to tell me? - correctness of technical solution - the solution is flawed? - nits We would also welcome suggestions as to whether review is needed by other groups than the SIP WG. And of course if you read it and find it absolutely perfect, send the chairs a mail at least to tell us. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 05:20:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy2YW-0001I8-Lt; Tue, 12 Jun 2007 05:20:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HwfyL-0002KY-TS for sip-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 11:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfyL-0002KK-Ju for sip@ietf.org; Fri, 08 Jun 2007 11:01:53 -0400 Received: from outbound-nd.cantata.com ([204.176.74.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfyK-00008i-D3 for sip@ietf.org; Fri, 08 Jun 2007 11:01:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 8 Jun 2007 11:01:48 -0400 Message-ID: In-Reply-To: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQ From: "Rafferty, James" To: "Gilad Shaham" , "Steve Langstaff" , "Christer Holmberg \(JO/LMF\)" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-Mailman-Approved-At: Tue, 12 Jun 2007 05:20:51 -0400 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like the idea of being clear where SIP INFO belongs (arguably only for use with SIP-T) and then having a BCP which identifies common places where SIP INFO is being used today, and then references the preferred practice (typically not using SIP INFO) or work in progress (for example, the mediactrl work) which will result in new practices. =20 The problem from a manufacturer's standpoint is that customers have existing products (for example, gateways) that use SIP INFO for DTMF passage and they insist on having compatibility with these bad practices built into other products, thus perpetuating the cycle of bad practice. A BCP might at least point the preferred way out of this mess. =20 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 sip-bounces@ietf.org Tue Jun 12 08:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5GG-0000ya-0t; Tue, 12 Jun 2007 08:14:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy5GE-0000yV-Rx for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5GE-0000yN-IL for sip@ietf.org; Tue, 12 Jun 2007 08:14:10 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5GC-0006zF-TH for sip@ietf.org; Tue, 12 Jun 2007 08:14:10 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4F380207E4; Tue, 12 Jun 2007 14:14:08 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-b1-466e8e10ea91 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 23A6E206A1; Tue, 12 Jun 2007 14:14:08 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:14:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Tue, 12 Jun 2007 14:14:06 +0200 Message-ID: <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQAMMMK2A= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> From: "Christer Holmberg (JO/LMF)" To: "Rafferty, James" , "Gilad Shaham" , "Steve Langstaff" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Jun 2007 12:14:07.0898 (UTC) FILETIME=[2D3357A0:01C7ACEB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, >I like the idea of being clear where SIP INFO belongs=20 >(arguably only for use with SIP-T) and then having a BCP=20 >which identifies common places where SIP INFO is being used=20 >today, and then references the preferred practice (typically=20 >not using SIP INFO) or work in progress (for example, the=20 >mediactrl work) which will result in new practices. =20 >=20 >The problem from a manufacturer's standpoint is that=20 >customers have existing products (for example, gateways) that=20 >use SIP INFO for DTMF passage and they insist on having=20 >compatibility with these bad practices built into other=20 >products, thus perpetuating the cycle of bad practice. >A BCP might at least point the preferred way out of this mess. =20 Normally, when we produce BCP type of documents, it's because there is a problem out there (people implement specs in different, uninteroperable, ways etc). Are we aware of real-life problems with using INFO for DTMF (or whatever else it's used for)? People have been doing it for a while (if we wanted to restrict something, it should have been done years ago...), it's fairly simple to implement - and it seems to work. The only problem is that much of the INFO usages are not defined in RFCs, but that's not always the fault of the implementors... Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 08:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5f7-0005QZ-CH; Tue, 12 Jun 2007 08:39:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy5f5-0005PO-Nh for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5f5-0005OA-C4 for sip@ietf.org; Tue, 12 Jun 2007 08:39:51 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5aq-00045G-BW for sip@ietf.org; Tue, 12 Jun 2007 08:35:29 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5CCZ9Fs009438; Tue, 12 Jun 2007 15:35:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:34:55 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:34:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-saml-02 Date: Tue, 12 Jun 2007 15:34:54 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03CDF405@esebe103.NOE.Nokia.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-saml-02 Thread-Index: Aces0fucrfmQnBbDRJiKX5ZPB1I70QAGdmhg References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> From: To: , X-OriginalArrivalTime: 12 Jun 2007 12:34:55.0366 (UTC) FILETIME=[14BFDA60:01C7ACEE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I did a review of this draft today and here are my comments to it: >- applicability - does it identify and solve a problem? I believe it solves a relevant problem which was identified=20 already within RFC 4484. >- readability - I didn't understand what it was trying to tell me? I found the draft easy to understand even if I had very little knowledge on SAML itself when starting to read the draft some time ago. >- correctness of technical solution - the solution is flawed? The approach itself seems to be sound, but some details still need polishing, like this one: 10. Verify that the SAML assertion contains an element, and that its value matches the value of the addr-spec of the SIP To header field. How is this matching to be done ? Shall the element exactly the SIP URI in the To header or can it contain just a part of it (like host part of the URI) ? The example in section 8 is like this: 19 20 example2.com 21 which is not a SIP URI, so I believe either the example or the normative text needs clarification. >- completeness - is there something missing? The draft refers to a number of open issues: 13. Open Issues A list of open issues can be found at: http://www.tschofenig.priv.at:8080/saml-sip/ It seems to me that those issues are still open within this version of the draft and should be addressed. I became concerned especially of issue 12 where there is an interoperability problem if the UAS only supports Identity-Info to refer to a certificate (per RFC 4474) instead of SAML assertion. This should be fixed in some way or another. @@ TODO: do we need to define a new SIP error response code for when a SAML assn signature is bad? e.g., '4xx Invalid SAML asssertion'. This TODO shall be resolved. To me an extra error code would make sense. >- nits I found these: In section 6.1.2: Although this profile is overview is cast in terms of a SIP INVITE transaction The first 'is' of the sentence sounds unnecessary. and also containing a the domain's (example.com) public key certificate The 'a' should be removed. The SIP URIs in Figure 2 should be checked: - Is Alice either Alice@example.com or alice@foo.com ? - Is Bob either bob@example.com or bob@example2.com ? - Should the SIP URIs of both Bob and Alice or neither of them have sip: prefix in the figure ? Currently Alice does not have it (in From) while Bob has (in To). In section 9.1.=20 * etc. This 'etc' should be removed.=20 Regards, Erkki >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 >Sent: 12.June.2007 12:14 >To: IETF SIP List >Subject: [Sip] draft-ietf-sip-saml-02 > >(As WG chair) > >Well it seems there is interest in this work, but it is not getting the >attention it deserves. >=20 >Some people also seem to think it is almost there, but we have=20 >no way of >judging that without seeing the what comments are being made=20 >against the >document (or of course reviewing it ourselves). > >This week is a quiet week (we supposedly finished our current WGLC >yesterday, and we are not yet ready to initiate another one, and the >draft closured deadlines for the forthcoming IETF are still a=20 >little bit >away). >=20 >We therefore task the working group to take the next 7 calendar days >(ending Monday 18th June) to open up: > >http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt > >And for everyone to post at least one comment on the document=20 >to the SIP >list. Posts can cover any of: > >- completeness - is there something missing? >- applicability - does it identify and solve a problem? >- readability - I didn't understand what it was trying to tell me? >- correctness of technical solution - the solution is flawed? >- nits > >We would also welcome suggestions as to whether review is needed by >other groups than the SIP WG. > >And of course if you read it and find it absolutely perfect, send the >chairs a mail at least to tell us. > >Regards > >Keith > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 08:42:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5hH-00069O-Mw; Tue, 12 Jun 2007 08:42:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy5hG-00069C-99 for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5hF-000693-Vx for sip@ietf.org; Tue, 12 Jun 2007 08:42:05 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy5hF-0005Px-LS for sip@ietf.org; Tue, 12 Jun 2007 08:42:05 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 12 Jun 2007 05:42:04 -0700 X-IronPort-AV: i="4.16,411,1175497200"; d="scan'208"; a="17784127:sNHT40801312" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 13:42:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Tue, 12 Jun 2007 13:42:02 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQAMMMK2AAALFsYA== References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" , "Rafferty, James" , "Steve Langstaff" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Jun 2007 12:42:02.0922 (UTC) FILETIME=[1397B8A0:01C7ACEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Comments inline. Cheers, Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 12, 2007 3:14 PM > To: Rafferty, James; Gilad Shaham; Steve Langstaff; Spencer Dawkins; > Robert Sparks; Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi, >=20 > >I like the idea of being clear where SIP INFO belongs > >(arguably only for use with SIP-T) and then having a BCP > >which identifies common places where SIP INFO is being used > >today, and then references the preferred practice (typically > >not using SIP INFO) or work in progress (for example, the > >mediactrl work) which will result in new practices. > > > >The problem from a manufacturer's standpoint is that > >customers have existing products (for example, gateways) that > >use SIP INFO for DTMF passage and they insist on having > >compatibility with these bad practices built into other > >products, thus perpetuating the cycle of bad practice. > >A BCP might at least point the preferred way out of this mess. >=20 > Normally, when we produce BCP type of documents, it's because there is a > problem out there (people implement specs in different, uninteroperable, > ways etc). >=20 > Are we aware of real-life problems with using INFO for DTMF (or whatever > else it's used for)? People have been doing it for a while (if we wanted > to restrict something, it should have been done years ago...), it's > fairly simple to implement - and it seems to work. Do we need DTMF via INFO for some kind of functionality KPML (or RFC 2833) does not provide? I'm not aware of such a case. One description of a problem with INFO can be found in this historical chat: http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html The explanation from the expired draft is as follows: Under this proposal, a User Agent MUST NOT send signaled digits or telephone-events using the INFO method if the event was ever represented as a tone (as media). Only signals originated as pure signaling MAY generate an INFO method. Failure to heed this requirement will result in double-detection of digits/events.=20 If INFO is used incorrectly by a pair of PSTN gateways (for example), the source gateway may detect a digit, send an INFO request which is lost, and retransmit that request. The target gateway would send the original in-band tone to the PSTN when the audio media arrives, later when the INFO arrives, the target gateway would render the same tone again. It is quite likely that the INFO will arrive after the media tone has been played (especially if multiple intermediaries are involved); the same digit would be played out again and this will frequently cause systems in the PSTN to detect the same digit signaled twice.=20 >=20 > The only problem is that much of the INFO usages are not defined in > RFCs, but that's not always the fault of the implementors... I think the implementors knew this was not standard or at most in very early draft mode when they implemented it. >=20 > Regards, >=20 > Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 08:55:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5uV-0001wr-77; Tue, 12 Jun 2007 08:55:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy5uU-0001wh-7G for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 08:55:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy5uT-0001wW-Sg for sip@ietf.org; Tue, 12 Jun 2007 08:55:45 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy5uS-000640-2L for sip@ietf.org; Tue, 12 Jun 2007 08:55:45 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D75122074B; Tue, 12 Jun 2007 14:55:41 +0200 (CEST) X-AuditID: c1b4fb3c-a8cebbb0000073d5-c3-466e97cdfb48 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9F7A920458; Tue, 12 Jun 2007 14:55:41 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:55:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Tue, 12 Jun 2007 14:55:40 +0200 Message-ID: <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQAMMMK2AAALFsYAABA4PQ References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> From: "Christer Holmberg (JO/LMF)" To: "Gilad Shaham" , "Rafferty, James" , "Steve Langstaff" , "Spencer Dawkins" , "Robert Sparks" , "Jonathan Rosenberg" X-OriginalArrivalTime: 12 Jun 2007 12:55:41.0322 (UTC) FILETIME=[FB65A6A0:01C7ACF0] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Are we aware of real-life problems with using INFO for DTMF (or whatever >>else it's used for)? People have been doing it for a while (if we wanted >>to restrict something, it should have been done years ago...), it's=20 >>fairly simple to implement - and it seems to work. >=20 >Do we need DTMF via INFO for some kind of functionality KPML (or RFC >2833) does not provide? I'm not aware of such a case. Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no matter if you use INFO or something else) is when you send them to an entity which does not have media access. >One description of a problem with INFO can be found in this historical >chat: >http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html >=20 >The explanation from the expired draft is as follows: >=20 >Under this proposal, a User Agent MUST NOT send signaled=20 >digits or telephone-events using the INFO method if the event=20 >was ever represented as a tone (as media). Only signals=20 >originated as pure signaling MAY generate an INFO method.=20 >Failure to heed this requirement will result in=20 >double-detection of digits/events.=20 >=20 >If INFO is used incorrectly by a pair of PSTN gateways (for=20 >example), the source gateway may detect a digit, send an INFO=20 >request which is lost, and retransmit that request. The=20 >target gateway would send the original in-band tone to the=20 >PSTN when the audio media arrives, later when the INFO=20 >arrives, the target gateway would render the same tone again.=20 >It is quite likely that the INFO will arrive after the media=20 >tone has been played (especially if multiple intermediaries=20 >are involved); the same digit would be played out again and=20 >this will frequently cause systems in the PSTN to detect the=20 >same digit signaled twice.=20 You can always mess up if you use things incorrectly. I don't think that is INFO specific. Regards, Christer >=20 >=20 >=20 >=20 > >=20 > > The only problem is that much of the INFO usages are not defined in=20 > > RFCs, but that's not always the fault of the implementors... >=20 > I think the implementors knew this was not standard or at=20 > most in very early draft mode when they implemented it. >=20 > >=20 > > Regards, > >=20 > > Christer >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 09:29:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6Qr-0004A5-06; Tue, 12 Jun 2007 09:29:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy6Qq-0004A0-4G for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 09:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6Qp-00049r-Qz for sip@ietf.org; Tue, 12 Jun 2007 09:29:11 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6Qp-0000jB-GP for sip@ietf.org; Tue, 12 Jun 2007 09:29:11 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 12 Jun 2007 06:29:10 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="17806230:sNHT41461816" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 14:29:08 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Tue, 12 Jun 2007 14:29:07 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQAMMMK2AAALFsYAABA4PQAACw8tA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" X-OriginalArrivalTime: 12 Jun 2007 13:29:08.0352 (UTC) FILETIME=[A7AE2000:01C7ACF5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: sip@ietf.org, "Rafferty, James" , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Here is another major problem with INFO - there is no header that states the purpose of INFO. The event header in subscriptions helps identify an event package. Therefore an implementation can easily detect if this event package is supported or not. With INFO it is much harder to detect the purpose of this INFO message. Currently AFAIK the content-type in INFO implicitly denotes this. If you are aiming towards a solution that keeps INFO for more usages, I would say that we need to resolve this issue first. I also think it would be a burden on implementors to do both KPML and INFO. Wouldn't it be easier for the implementors that did INFO to switch to KPML instead of the entire industry doing both? Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 12, 2007 3:56 PM > To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins; > Robert Sparks; Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi, >=20 > >>Are we aware of real-life problems with using INFO for DTMF (or > whatever > >>else it's used for)? People have been doing it for a while (if we > wanted > >>to restrict something, it should have been done years ago...), it's > >>fairly simple to implement - and it seems to work. > > > >Do we need DTMF via INFO for some kind of functionality KPML (or RFC > >2833) does not provide? I'm not aware of such a case. >=20 > Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no > matter if you use INFO or something else) is when you send them to an > entity which does not have media access. >=20 > >One description of a problem with INFO can be found in this historical > >chat: > >http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html > > > >The explanation from the expired draft is as follows: > > > >Under this proposal, a User Agent MUST NOT send signaled > >digits or telephone-events using the INFO method if the event > >was ever represented as a tone (as media). Only signals > >originated as pure signaling MAY generate an INFO method. > >Failure to heed this requirement will result in > >double-detection of digits/events. > > > >If INFO is used incorrectly by a pair of PSTN gateways (for > >example), the source gateway may detect a digit, send an INFO > >request which is lost, and retransmit that request. The > >target gateway would send the original in-band tone to the > >PSTN when the audio media arrives, later when the INFO > >arrives, the target gateway would render the same tone again. > >It is quite likely that the INFO will arrive after the media > >tone has been played (especially if multiple intermediaries > >are involved); the same digit would be played out again and > >this will frequently cause systems in the PSTN to detect the > >same digit signaled twice. >=20 > You can always mess up if you use things incorrectly. I don't think that > is INFO specific. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > > > > > > > > > > > > The only problem is that much of the INFO usages are not defined in > > > RFCs, but that's not always the fault of the implementors... > > > > I think the implementors knew this was not standard or at > > most in very early draft mode when they implemented it. > > > > > > > > Regards, > > > > > > Christer > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 09:53:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6oV-0005yg-CT; Tue, 12 Jun 2007 09:53:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy6oT-0005yY-O9 for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 09:53:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy6oT-0005yN-EU for sip@ietf.org; Tue, 12 Jun 2007 09:53:37 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy6oS-0006aH-Lm for sip@ietf.org; Tue, 12 Jun 2007 09:53:37 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E5C1121327; Tue, 12 Jun 2007 15:53:35 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-44-466ea55f253c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AE19421305; Tue, 12 Jun 2007 15:53:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 15:53:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Tue, 12 Jun 2007 15:53:34 +0200 Message-ID: <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcepwU2YaI1uGjbLS0O2NPNYzs/tqQAADskgAAJdMZAAAT+DYAADSHXQAMMMK2AAALFsYAABA4PQAACw8tAAAOmZEA== References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> From: "Christer Holmberg (JO/LMF)" To: "Gilad Shaham" X-OriginalArrivalTime: 12 Jun 2007 13:53:35.0336 (UTC) FILETIME=[12121E80:01C7ACF9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: sip@ietf.org, "Rafferty, James" , Steve Langstaff X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Here is another major problem with INFO - there is no header=20 >that states the purpose of INFO. >The event header in subscriptions helps identify an event package. >Therefore an implementation can easily detect if this event=20 >package is supported or not. With INFO it is much harder to=20 >detect the purpose of this INFO message. Currently AFAIK the=20 >content-type in INFO implicitly denotes this. If I send a DTMF digit, the purpose is to send a DTMF digit :) >If you are aiming towards a solution that keeps INFO for more=20 >usages, I would say that we need to resolve this issue first. I am just trying to figure out what the problem really is. Regards, Christer >I also think it would be a burden on implementors to do both=20 >KPML and INFO. Wouldn't it be easier for the implementors=20 >that did INFO to switch to KPML instead of the entire=20 >industry doing both? > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 12, 2007 3:56 PM > > To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer=20 > Dawkins;=20 > > Robert Sparks; Jonathan Rosenberg > > Cc: sip@ietf.org > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > >=20 > > Hi, > >=20 > > >>Are we aware of real-life problems with using INFO for DTMF (or > > whatever > > >>else it's used for)? People have been doing it for a while (if we > > wanted > > >>to restrict something, it should have been done years=20 > ago...), it's=20 > > >>fairly simple to implement - and it seems to work. > > > > > >Do we need DTMF via INFO for some kind of functionality=20 > KPML (or RFC > > >2833) does not provide? I'm not aware of such a case. > >=20 > > Regarding 2833, I guess the main idea of sending DTMFs=20 > out-of-band (no=20 > > matter if you use INFO or something else) is when you send=20 > them to an=20 > > entity which does not have media access. > >=20 > > >One description of a problem with INFO can be found in this > historical > > >chat: > > >http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html > > > > > >The explanation from the expired draft is as follows: > > > > > >Under this proposal, a User Agent MUST NOT send signaled digits or=20 > > >telephone-events using the INFO method if the event was ever=20 > > >represented as a tone (as media). Only signals originated as pure=20 > > >signaling MAY generate an INFO method. > > >Failure to heed this requirement will result in=20 > double-detection of=20 > > >digits/events. > > > > > >If INFO is used incorrectly by a pair of PSTN gateways=20 > (for example),=20 > > >the source gateway may detect a digit, send an INFO=20 > request which is=20 > > >lost, and retransmit that request. The target gateway=20 > would send the=20 > > >original in-band tone to the PSTN when the audio media=20 > arrives, later=20 > > >when the INFO arrives, the target gateway would render the=20 > same tone=20 > > >again. > > >It is quite likely that the INFO will arrive after the=20 > media tone has=20 > > >been played (especially if multiple intermediaries are=20 > involved); the=20 > > >same digit would be played out again and this will=20 > frequently cause=20 > > >systems in the PSTN to detect the same digit signaled twice. > >=20 > > You can always mess up if you use things incorrectly. I don't think > that > > is INFO specific. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > > > > > > > > > > > > > > > > > > The only problem is that much of the INFO usages are not defined > in > > > > RFCs, but that's not always the fault of the implementors... > > > > > > I think the implementors knew this was not standard or at most in=20 > > > very early draft mode when they implemented it. > > > > > > > > > > > Regards, > > > > > > > > Christer > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 12:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9aE-00007s-L7; Tue, 12 Jun 2007 12:51:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hy9aC-000069-I1 for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 12:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy9aC-000061-8S for sip@ietf.org; Tue, 12 Jun 2007 12:51:04 -0400 Received: from mvimap.mailvision.net ([212.143.248.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy9a9-0005dY-IO for sip@ietf.org; Tue, 12 Jun 2007 12:51:04 -0400 Received: from localhost (localhost [127.0.0.1]) by mvimap.mailvision.net (Postfix) with ESMTP id 91BDE768E65; Tue, 12 Jun 2007 18:48:42 +0300 (IDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-10 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.009, BAYES_00=-2.599] Received: from mvimap.mailvision.net ([127.0.0.1]) by localhost (mvimap.mailvision.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2kIfrHGUeos; Tue, 12 Jun 2007 18:48:37 +0300 (IDT) Received: from [127.0.0.1] (unknown [192.168.0.34]) by mvimap.mailvision.net (Postfix) with ESMTP id 61C0C768E63; Tue, 12 Jun 2007 18:48:37 +0300 (IDT) Message-ID: <466EDBEF.5040406@mailvision.com> Date: Tue, 12 Jun 2007 19:46:23 +0200 From: Diego B User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Gilad Shaham Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: sip@ietf.org, "Rafferty, James" , Steve Langstaff , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline Gilad Shaham wrote: > Hi, > > Here is another major problem with INFO - there is no header that states > the purpose of INFO. > If the conte-type is correct, the payload is a DTMF digit. No needs for a special header. > The event header in subscriptions helps identify an event package. > Therefore an implementation can easily detect if this event package is > supported or not. You can state in the Accept header that you support the content-type for the DTMF paylod ( application/dtmf or application/dtmf-relay ) > With INFO it is much harder to detect the purpose of > this INFO message. Currently AFAIK the content-type in INFO implicitly > denotes this. > > So, why is harder ? > If you are aiming towards a solution that keeps INFO for more usages, I > would say that we need to resolve this issue first. > > I do not see any issue here > I also think it would be a burden on implementors to do both KPML and > INFO. Wouldn't it be easier for the implementors that did INFO to switch > to KPML instead of the entire industry doing both? > > INFO is very easy to implement. So I dont't see any problem to keep the INFO implementation until KPML is adopted. Or maybe keep both. > Gilad > > Diego B >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) >> > [mailto:christer.holmberg@ericsson.com] > >> Sent: Tuesday, June 12, 2007 3:56 PM >> To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins; >> Robert Sparks; Jonathan Rosenberg >> Cc: sip@ietf.org >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >> >> >> Hi, >> >> >>>> Are we aware of real-life problems with using INFO for DTMF (or >>>> >> whatever >> >>>> else it's used for)? People have been doing it for a while (if we >>>> >> wanted >> >>>> to restrict something, it should have been done years ago...), it's >>>> fairly simple to implement - and it seems to work. >>>> >>> Do we need DTMF via INFO for some kind of functionality KPML (or RFC >>> 2833) does not provide? I'm not aware of such a case. >>> >> Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no >> matter if you use INFO or something else) is when you send them to an >> entity which does not have media access. >> >> >>> One description of a problem with INFO can be found in this >>> > historical > >>> chat: >>> http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html >>> >>> The explanation from the expired draft is as follows: >>> >>> Under this proposal, a User Agent MUST NOT send signaled >>> digits or telephone-events using the INFO method if the event >>> was ever represented as a tone (as media). Only signals >>> originated as pure signaling MAY generate an INFO method. >>> Failure to heed this requirement will result in >>> double-detection of digits/events. >>> >>> If INFO is used incorrectly by a pair of PSTN gateways (for >>> example), the source gateway may detect a digit, send an INFO >>> request which is lost, and retransmit that request. The >>> target gateway would send the original in-band tone to the >>> PSTN when the audio media arrives, later when the INFO >>> arrives, the target gateway would render the same tone again. >>> It is quite likely that the INFO will arrive after the media >>> tone has been played (especially if multiple intermediaries >>> are involved); the same digit would be played out again and >>> this will frequently cause systems in the PSTN to detect the >>> same digit signaled twice. >>> >> You can always mess up if you use things incorrectly. I don't think >> > that > >> is INFO specific. >> >> Regards, >> >> Christer >> >> >> >> >>> >>> >>> >>>> The only problem is that much of the INFO usages are not defined >>>> > in > >>>> RFCs, but that's not always the fault of the implementors... >>>> >>> I think the implementors knew this was not standard or at >>> most in very early draft mode when they implemented it. >>> >>> >>>> Regards, >>>> >>>> Christer >>>> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 15:26:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyC0U-0001T9-7g; Tue, 12 Jun 2007 15:26:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyC0S-0001Sp-4Y for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 15:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyC0R-0001SZ-QZ for sip@ietf.org; Tue, 12 Jun 2007 15:26:19 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyC0O-0008Lr-QU for sip@ietf.org; Tue, 12 Jun 2007 15:26:19 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l5CJQ3At031408; Tue, 12 Jun 2007 13:26:04 -0600 Message-ID: <466EF33C.7080807@ntt-at.com> Date: Tue, 12 Jun 2007 12:25:48 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "sip@ietf.org List" , Volker Hilt Subject: [Sip] WGLC Review: draft-ietf-sip-session-policy-framework-01 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-session-policy-framework-01 Reviewer: Shida Schubert Review Date: 11 June 2007 Review Deadline: 11 June 2007 Status: WGLC I apologize for submitting the review past deadline. Summary: This draft is basically ready for publication, but has nits and some clarification that should be fixed/added before publication. Comments: ---------- I reviewed the diff for this document as compared to the version I previously reviewed: I believe all my previous concerns have been addressed. I also re-read the document through which I found some areas that need some clarifications and additional nits/editorials. Clarifications needed: ------ C1) Section 4.4.1, 2nd para, 2nd last sentence. - not receiving policy and not receiving any response the same thing? > If not may want to clarify this. C2) Section 4.4.1 The token is mentioned everywhere, but looking at the event packages there is no token defined. Do you expect token to be something implicit that administrator somehow configures the policy server and UA so they implicitly know what token is and how to find it in the policy provided by the policy server? I understand that token itself may have flexibility in its value, but where to look for the token SHOULD be specified explicitly. C3) Section 4.4.1 For existing dialog, what is the impact of policy channel failing? > Would it affect the whole dialog or just the usage? > Currently it reads like it would affect the dialog which may not be desirable. (Section 4.4.6 reads "This means that, the UA MUST cancel or reject a pending INVITE transaction for the session or terminate the session if it is already in progress." e.g) UAC tries to change the codec mid-dialog > sends the new SDP to policy server > Policy server is offline or returns global class error > What happens now? C4) Section 4.4.2 Proxy's behavior on policy-id and token is completely missing. paragraph 2 notes how proxy MUST NOT reject the request if the policy-id contains the associated policy server's URI but on section 4.4.1, there is enough text describing how some proxy may base their pass-through on token, so I think text on proxy behavior surrounding token in this section is an appropriate addition. C5) Section 4.4.2 It may be appropriate to add some text on RR by proxy wanting to ensure UA passes the same proxies/policy servers, rather than UA maintaining a list of policy servers to contact mid-dialog. UA always contacting the same policy servers contacted at the initial session setup, even after the signaling path has changed seems unreasonable and ineffective. * I don't have a strong opinion on this, don't mind the current spec but wondered if you considered this. C6) Section 4.4.3 As UAS does not use the policy-Id, text SHOULD be added to mention that if the list of policy server changes in mid-dialog that it should contact the policy servers again. (Text can be added instead in section 4.4.5 - last paragraph encouraging the re-visit to the policy servers) * This is not problematic with UAC as proxy would return 488 with policy server URI, alerting the UAC that list of policy server that need to be contacted have changed. Nits/Editorials: ------ N1) Section 1, 1st para, 2nd sentence. [page mode messaging is not divorced from the actual session] OLD: However, proxies are divorced from the actual sessions - audio, video, and messaging - that SIP establishes. NEW: However, proxies are divorced from the actual sessions - audio, video, and session mode messaging - that SIP establishes. N2) Section 1, 1st para, last sentence. Text on S/MIME plays no roles here, its context seems kind of odd. I believe the text only causes confusion thus should be removed. N3) Section 4.4.1, 4th - 6th para Seems out of place. These paragraphs focus on policy-id usage and its purpose, it should go into section 4.4.7.1. N4) Section 4.4.1, 5th para 2nd sentence. [proxies > proxy] N5) Section 4.4.1, 5th para, last sentence. [unnecessary "that"] OLD: combination that has configured the associated NEW: combination has configured the associated N6) Section 4.4.2, 2nd para, 2nd sentence [this policy server > associated policy server] OLD: The proxy SHOULD remove the Policy-Id header value for this policy server from the Policy-Id header field before forwarding the request. NEW: The proxy SHOULD remove the Policy-Id header value for the assocaited policy server from the Policy-Id header field before forwarding the request. N7) Section 4.4.6, 1st para, 1st sentence [add MUST before apply] OLD: A UA compliant to this specification MUST contact the discovered policy servers and apply session policies to an offer or answer before using the offer or answer. NEW: A UA compliant to this specification MUST contact the discovered policy servers and MUST apply session policies to an offer or answer before using the offer or answer. N8) Section 4.4.6, last para OLD: A UA MUST inform the policy server when a session is terminated via the policy channel. This enables a policy server to free all resources it may have allocated for this session. A policy server can indicate via the policy channel that it does not need to be contacted at the end of a session. In this case, the UA SHOULD NOT inform the policy server about the termination of the session. NEW: A UA MUST inform the policy server when a session is terminated via the policy channel unless, a policy server indicates via the policy channel that it does not need to be contacted at the end of a session. This enables a policy server to free all resources it may have allocated for this session. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 16:23:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCQH-0002rx-Bj; Tue, 12 Jun 2007 15:53:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyCNu-0007ti-SS for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCNt-0007nk-5Z; Tue, 12 Jun 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyCNs-0001in-Pc; Tue, 12 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8BB4C2AC8C; Tue, 12 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HyCNO-0005lS-A4; Tue, 12 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 12 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-answermode-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@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 : Requesting Answering Modes for the Session Initiation Protocol (SIP) Author(s) : D. Willis, A. Allen Filename : draft-ietf-sip-answermode-04.txt Pages : 25 Date : 2007-6-12 This document defines extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or instead accepts the request without waiting on user input. The second header, "Priv- Answer-Mode" is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as Push-to-Talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-answermode-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-answermode-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: <2007-6-12130051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-answermode-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-answermode-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-12130051.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Tue Jun 12 16:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCwG-0001eV-5L; Tue, 12 Jun 2007 16:26:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyCwE-0001dy-TF for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 16:26:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyCwE-0001dX-II for sip@ietf.org; Tue, 12 Jun 2007 16:26:02 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyCwB-0005hT-Of for sip@ietf.org; Tue, 12 Jun 2007 16:26:02 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HyCyl-0000kf-DU; Tue, 12 Jun 2007 15:28:40 -0500 In-Reply-To: <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Tue, 12 Jun 2007 15:25:12 -0500 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 12, 2007, at 8:53 AM, Christer Holmberg (JO/LMF) wrote: > >> If you are aiming towards a solution that keeps INFO for more >> usages, I would say that we need to resolve this issue first. > > I am just trying to figure out what the problem really is. This is ancient, badly written in a hurry, and full of errors, but it might help: http://www.softarmor.com/wgdb/docs/draft-willis-sip-infopackage-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 sip-bounces@ietf.org Tue Jun 12 17:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyELb-0004qp-FB; Tue, 12 Jun 2007 17:56:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyELZ-0004pb-Dl for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 17:56:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyELZ-0004oz-3n for sip@ietf.org; Tue, 12 Jun 2007 17:56:17 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyELV-00068I-Ti for sip@ietf.org; Tue, 12 Jun 2007 17:56:16 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HyEO4-0005Jq-RG for sip@ietf.org; Tue, 12 Jun 2007 16:58:54 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6786E9B7-7AC6-4B39-9A3E-C80D3FEC45A8@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 12 Jun 2007 16:55:28 -0500 To: SIP IETF X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Re: I-D ACTION:draft-ietf-sip-answermode-04.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 12, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > 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 : Requesting Answering Modes for the Session Initiation > Protocol (SIP) > Author(s) : D. Willis, A. Allen > Filename : draft-ietf-sip-answermode-04.txt > Pages : 25 > Date : 2007-6-12 This version is a third attempt to address the sponsoring chair's (that would be Keith) comments as raised during the PROTO writeup prior to sending this puppy off to the IESG. Note that this is AFTER WGLC. Two points: 1) Thirty percent of the supporting text has been touched in the process. If you care, you might want to eyeball the latest draft. There should be no impacts to implementors (except, perhaps, cognitive). 2) Given the depth and breadth of the comments during PROTO writeup, clearly, we aren't doing all that good of a job in reviewing drafts during WGLC. The floor is open on how to do a better job. Anybody have ideas? -- 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 sip-bounces@ietf.org Tue Jun 12 17:57:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEMW-0006zp-TZ; Tue, 12 Jun 2007 17:57:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyEMU-0006li-OA for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 17:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEMU-0006jk-DY for sip@ietf.org; Tue, 12 Jun 2007 17:57:14 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEMT-0006tP-Rf for sip@ietf.org; Tue, 12 Jun 2007 17:57:14 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 12 Jun 2007 14:57:11 -0700 X-IronPort-AV: i="4.16,413,1175497200"; d="scan'208"; a="18027936:sNHT44833060" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 22:57:10 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Tue, 12 Jun 2007 22:57:04 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097EC4B@EMAILEMEA3.jnpr.net> In-Reply-To: <466EDBEF.5040406@mailvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcetEezuUEeXdiLcQeOEPDB2ihH/kQAI4bFQ References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <466EDBEF.5040406@mailvision.com> From: "Gilad Shaham" To: "Diego B" X-OriginalArrivalTime: 12 Jun 2007 21:57:10.0981 (UTC) FILETIME=[A0BE2F50:01C7AD3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: sip@ietf.org, "Rafferty, James" , Steve Langstaff , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org In my opinion, content-type is not good enough. What would one do if it is Multipart-Mixed? We are talking about something general, right? What if the same content type is to be used for 2 different info usages? Christer asked if there are real life problems with using INFO for DTMF, I think it's one of the problems today with INFO in general. I'm sure it can be solved (e.g., the old draft Dean sent), but it still requires change in the spec. Returning to the question, "why not do INFO for DTMF?". Let's assume there are good solutions to all the problems one can find with INFO for DTMF then: 1. It might be different than existing implementations therefore implementors that already have it will still need to change their implementation. 2. It might simply provide a subset/same functionality KPML provides. Regards, Gilad > -----Original Message----- > From: Diego B [mailto:diegob@mailvision.com] > Sent: Tuesday, June 12, 2007 8:46 PM > To: Gilad Shaham > Cc: Christer Holmberg (JO/LMF); sip@ietf.org; Rafferty, James; Steve > Langstaff > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > Inline >=20 > Gilad Shaham wrote: > > Hi, > > > > Here is another major problem with INFO - there is no header that states > > the purpose of INFO. > > > If the conte-type is correct, the payload is a DTMF digit. No needs for > a special header. > > The event header in subscriptions helps identify an event package. > > Therefore an implementation can easily detect if this event package is > > supported or not. > You can state in the Accept header that you support the content-type for > the DTMF paylod ( application/dtmf or application/dtmf-relay ) > > With INFO it is much harder to detect the purpose of > > this INFO message. Currently AFAIK the content-type in INFO implicitly > > denotes this. > > > > > So, why is harder ? > > If you are aiming towards a solution that keeps INFO for more usages, I > > would say that we need to resolve this issue first. > > > > > I do not see any issue here > > I also think it would be a burden on implementors to do both KPML and > > INFO. Wouldn't it be easier for the implementors that did INFO to switch > > to KPML instead of the entire industry doing both? > > > > > INFO is very easy to implement. So I dont't see any problem to keep the > INFO implementation > until KPML is adopted. Or maybe keep both. > > Gilad > > > > > Diego B > >> -----Original Message----- > >> From: Christer Holmberg (JO/LMF) > >> > > [mailto:christer.holmberg@ericsson.com] > > > >> Sent: Tuesday, June 12, 2007 3:56 PM > >> To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins; > >> Robert Sparks; Jonathan Rosenberg > >> Cc: sip@ietf.org > >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >> > >> > >> Hi, > >> > >> > >>>> Are we aware of real-life problems with using INFO for DTMF (or > >>>> > >> whatever > >> > >>>> else it's used for)? People have been doing it for a while (if we > >>>> > >> wanted > >> > >>>> to restrict something, it should have been done years ago...), it's > >>>> fairly simple to implement - and it seems to work. > >>>> > >>> Do we need DTMF via INFO for some kind of functionality KPML (or RFC > >>> 2833) does not provide? I'm not aware of such a case. > >>> > >> Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no > >> matter if you use INFO or something else) is when you send them to an > >> entity which does not have media access. > >> > >> > >>> One description of a problem with INFO can be found in this > >>> > > historical > > > >>> chat: > >>> http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html > >>> > >>> The explanation from the expired draft is as follows: > >>> > >>> Under this proposal, a User Agent MUST NOT send signaled > >>> digits or telephone-events using the INFO method if the event > >>> was ever represented as a tone (as media). Only signals > >>> originated as pure signaling MAY generate an INFO method. > >>> Failure to heed this requirement will result in > >>> double-detection of digits/events. > >>> > >>> If INFO is used incorrectly by a pair of PSTN gateways (for > >>> example), the source gateway may detect a digit, send an INFO > >>> request which is lost, and retransmit that request. The > >>> target gateway would send the original in-band tone to the > >>> PSTN when the audio media arrives, later when the INFO > >>> arrives, the target gateway would render the same tone again. > >>> It is quite likely that the INFO will arrive after the media > >>> tone has been played (especially if multiple intermediaries > >>> are involved); the same digit would be played out again and > >>> this will frequently cause systems in the PSTN to detect the > >>> same digit signaled twice. > >>> > >> You can always mess up if you use things incorrectly. I don't think > >> > > that > > > >> is INFO specific. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> > >>> > >>> > >>> > >>>> The only problem is that much of the INFO usages are not defined > >>>> > > in > > > >>>> RFCs, but that's not always the fault of the implementors... > >>>> > >>> I think the implementors knew this was not standard or at > >>> most in very early draft mode when they implemented it. > >>> > >>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 19:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyG4b-000452-2e; Tue, 12 Jun 2007 19:46:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyG4Y-00043g-So for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 19:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyG4Y-00043U-C7 for sip@ietf.org; Tue, 12 Jun 2007 19:46:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyG4W-0006VS-1j for sip@ietf.org; Tue, 12 Jun 2007 19:46:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2007 19:46:44 -0400 X-IronPort-AV: i="4.16,413,1175486400"; d="scan'208"; a="62591749:sNHT45156072" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CNkhPv016403; Tue, 12 Jun 2007 19:46:43 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5CNkZBe029456; Tue, 12 Jun 2007 23:46:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 19:46:35 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 19:46:35 -0400 Message-ID: <466F3059.1030109@cisco.com> Date: Tue, 12 Jun 2007 19:46:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Re: I-D ACTION:draft-ietf-sip-answermode-04.txt References: <6786E9B7-7AC6-4B39-9A3E-C80D3FEC45A8@softarmor.com> In-Reply-To: <6786E9B7-7AC6-4B39-9A3E-C80D3FEC45A8@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2007 23:46:35.0284 (UTC) FILETIME=[E95F5540:01C7AD4B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1614; t=1181692003; x=1182556003; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Re=3A=20I-D=20ACTION=3Adraft-ietf-sip-answerm ode-04.txt |Sender:=20 |To:=20Dean=20Willis=20; bh=5kWHYk+kwAC606E4jCWKlwryO3n4C4m/vr5JjWZhwGM=; b=LhJqFRadyM2vc8K/OIXCT/N6Cfjp1Tw2W9sgdEL2mZcgpjYX48bHZv4hOxMZZdB5tN3NgrEX Lh9Z1aDPXJX5kffBZMdp5PiS5AD5vZJu0rdTv9qJaGZdEkmSDsEkEYR6; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This looks fine to me. Paul Dean Willis wrote: > > On Jun 12, 2007, at 2:50 PM, Internet-Drafts@ietf.org wrote: > >> 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 : Requesting Answering Modes for the Session >> Initiation Protocol (SIP) >> Author(s) : D. Willis, A. Allen >> Filename : draft-ietf-sip-answermode-04.txt >> Pages : 25 >> Date : 2007-6-12 > > This version is a third attempt to address the sponsoring chair's (that > would be Keith) comments as raised during the PROTO writeup prior to > sending this puppy off to the IESG. Note that this is AFTER WGLC. > > Two points: > > 1) Thirty percent of the supporting text has been touched in the > process. If you care, you might want to eyeball the latest draft. There > should be no impacts to implementors (except, perhaps, cognitive). > > 2) Given the depth and breadth of the comments during PROTO writeup, > clearly, we aren't doing all that good of a job in reviewing drafts > during WGLC. The floor is open on how to do a better job. Anybody have > ideas? > > -- > 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 sip-bounces@ietf.org Tue Jun 12 20:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyGhi-00076O-DN; Tue, 12 Jun 2007 20:27:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyGhg-00076J-9M for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 20:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyGhf-00076B-W5 for sip@ietf.org; Tue, 12 Jun 2007 20:27:15 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyGhe-0003OR-MN for sip@ietf.org; Tue, 12 Jun 2007 20:27:15 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l5D0Pu300737 for ; Wed, 13 Jun 2007 00:25:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Date: Tue, 12 Jun 2007 19:27:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10D8D9AE@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10C66502@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of last hop exception Thread-Index: AcepORQ113rve+TSQiWe2/BTJ135yQAColOAAQNrROA= References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> <46685ABD.7080101@cisco.com> <1ECE0EB50388174790F9694F77522CCF10C66502@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I didn't get any feedback from the list on this topic that I'm trying to close. Comments?=20 > -----Original Message----- > From: Audet, Francois (SC100:3055)=20 > Sent: Thursday, June 07, 2007 14:14 > To: Jonathan Rosenberg; Jeroen van Bemmel > Cc: sip@ietf.org > Subject: RE: [Sip] Re: draft-ietf-sip-sips-04: 403 instead of=20 > last hop exception >=20 > =20 >=20 > > However to be honest we need to explicitly indicate that=20 > the problem=20 > > was sips-to-sip so that the original UA can decide whether=20 > to retry.=20 > > Thus I'd suggest a new 4xx code. >=20 >=20 > I'm fine with this. >=20 >=20 > Let me propose 418 (SIPS Not Allowed) >=20 > With the following description: >=20 > The server cannot process the request because the SIPS=20 > scheme is not=20 > allowed. The UAC SHOULD retry the request, this time,=20 > using a SIP URI. > This response differs from 416 in that the server=20 > recognizes the SIPS > URI, but it is not allowed (e.g., because the UAS=20 > registered with > a SIP Contact header field). >=20 > (And the current text on proxies not recursing on this will apply) >=20 > (Note: existing implementations will treat it as 400, which=20 > is intended behavior, i.e., it will not automatically=20 > re-attempt anything). >=20 > If you support this, or are against this, please voice your=20 > opinion. If you don't care that much, just don't say anything :^) >=20 > Now, the next logical quesiton is for sip-to-sips. >=20 > Currently, the text has this text about proxies that may=20 > decide to use either 403 or 3XX to redirect to a SIPS URI. We=20 > have a similar problem here that some proxy in the middle may=20 > decide to recurse on it (which would break the last hop=20 > upgrade prohibition). >=20 > Do we need a 419 (SIPS Required) as well? Or are we happy=20 > with the current text? >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 12 23:02:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJ7T-0003mx-KX; Tue, 12 Jun 2007 23:02:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyJ7R-0003i2-TA for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 23:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJ7R-0003gr-I7 for sip@ietf.org; Tue, 12 Jun 2007 23:02:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyJ7Q-0004u3-5s for sip@ietf.org; Tue, 12 Jun 2007 23:02:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 20:02:00 -0700 X-IronPort-AV: i="4.16,414,1175497200"; d="scan'208"; a="163612363:sNHT46416033" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5D31xSv000890 for ; Tue, 12 Jun 2007 20:01:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5D31xaI006819 for ; Wed, 13 Jun 2007 03:01:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 20:01:59 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 20:01:59 -0700 Message-ID: <466F5E26.2000709@cisco.com> Date: Tue, 12 Jun 2007 23:01:58 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2007 03:01:59.0519 (UTC) FILETIME=[358F9EF0:01C7AD67] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2640; t=1181703719; x=1182567719; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20UA=20Loose=20Routing=20Issue=20#1=3A=20Backwards=20compatibil ity |Sender:=20; bh=0+JTP8BkRztJHWSTzyz6D4cx1b0ffghY/PQLY8hmor0=; b=e2eQ0BANdx+BlVU5DqTKEm083RYtmr3y46TSmPnVYEyLZCKSyUXNbXqlOsFt79d0+ZhpYWlw +1u5dUIQPRPAofBqxV7aqs5pX0o9/iVvX5+/hyfjSvXOWHibqEEcfFo2; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I've recently revised my draft on UA loose routing. You can pick it up here: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loose-route-01.txt This draft is meant to fulfill one of our charter items: Feb 2008 Delivering request-URI and parameters to UAS via proxy to IESG (PS) As folks may recall, the GRUU spec used to have these things called grids, which allowed a UA to add its own parameters to the GRUU before handing it out. Several GRUU revisions back, this function got yanked because it was recognized that the problem was more general than GRUU, and would be useful for AOR as well. Two IETFs back I presented this draft briefly during a SIP session. There was a lot of interest and people liked it architecturally, however there were two open issues that needed to get resolved. This mail is meant to start discussion on one of them - backwards compatibility. THe mechanism basically changes the way proxies handle requests. Instead of rewriting the request URI for out-of-dialog requests, they'll push a route header and leave the r-uri alone. This allows the original R-URI and any parameters it contains to get delivered to the UAS. So, the main issue is, what kinds of backwards compatibility problems will this cause. The draft provides a basic mechanism whereby a UA includes an option tag in the REGISTER, and the registrar indicates that it is using this mechanism or not. So we can negotiate this between a UA and registrar easily. Now, the problem is with intermediate proxies. If there is an edge proxy between the UA and its registrar, it will now see requests targeted to the UA, which contain a Route header beyond itself, even though it thinks its the edge proxy and the last point of contact before the UA. Technically, if this edge proxy is compliant to rfc3261 it would work. However, the question is whether proxies in the wild would properly work in this case. If folks can comment based on their own products, or their experiences, on whether they think this would work, or concerns they have, that would be great. THere are solutions that would allow us to disable the mechanism when intermediate proxies don't support it, but they are more complex and I'd rather avoid it. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 12 23:05:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJBG-00066B-0d; Tue, 12 Jun 2007 23:05:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyJBE-000663-C7 for sip-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 23:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyJBE-00065v-2b for sip@ietf.org; Tue, 12 Jun 2007 23:05:56 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyJBD-0006Yu-Oa for sip@ietf.org; Tue, 12 Jun 2007 23:05:56 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 12 Jun 2007 20:05:55 -0700 X-IronPort-AV: i="4.16,414,1175497200"; d="scan'208"; a="493179883:sNHT43365904" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5D35tJx030836 for ; Tue, 12 Jun 2007 20:05:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5D35ttV013034 for ; Wed, 13 Jun 2007 03:05:55 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 20:05:54 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 20:05:54 -0700 Message-ID: <466F5F11.8060507@cisco.com> Date: Tue, 12 Jun 2007 23:05:53 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2007 03:05:54.0462 (UTC) FILETIME=[C19913E0:01C7AD67] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1330; t=1181703955; x=1182567955; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20UA=20loose=20route=20issue=20#2=3A=20standardized=20URI=20par ams=20or=20not |Sender:=20; bh=6FTuASIhPgNduIq4+Zv0dTNqQn0jySC2Jc82u/ibu0w=; b=uzzqruiw4ByYHgarEgXxbsjoP9GQYS3R0gEfyKGDrhxpAMMPrgZp7kbgWqQHbsZdwXQxi/0F 06QFUvVIziJR5zuLdD8NYbFmO30Fr7B7ILm8AufVHhaNjx3qU+0Jqlfp; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] UA loose route issue #2: standardized URI params or not X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With the proposed UA loose routing mechanism, a UA can mint new AORs or new GRUUs by simply adding URI params to its AOR or gruu, and passing them around. The question is, do we need to standardize the set of URI params that the UA can add to its AOR or GRUU? One argument in favor of such a thing is that it avoids conflicts with URI params that might be meaningful to the home proxy, unbeknownst to the UA. It also helps guide implementations on what to expect in URIs when this capability is used. On the other hand, by not standardizing a URI param, we can allow UA to use any number of params using names of their liking, which is nice and flexible. A middle-ground is to standardize a prefix, kind of like what we did for media feature tags in RFC 3840 (though not a shining example of a successful RFC). I've been back and forth on this, but based on the principle of least surprise, would propose a specific URI parameter be chosen. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Wed Jun 13 04:39:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyONy-0002oq-Ma; Wed, 13 Jun 2007 04:39:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyONw-0002og-PL for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 04:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyONw-0002oX-Fo for sip@ietf.org; Wed, 13 Jun 2007 04:39:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyONu-0002yr-Ua for sip@ietf.org; Wed, 13 Jun 2007 04:39:24 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 56D31210E1; Wed, 13 Jun 2007 10:39:22 +0200 (CEST) X-AuditID: c1b4fb3e-af676bb0000007e1-36-466fad3ad957 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FC69210DE; Wed, 13 Jun 2007 10:39:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:39:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 10:39:20 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CE27F@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA Loose Routing: Alternative using P-Called-Party thread-index: AcetllZGMfnvBZEtRhmhebagorhfSQ== From: "Christer Holmberg (JO/LMF)" To: , "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Jun 2007 08:39:21.0685 (UTC) FILETIME=[56D50850:01C7AD96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Sip] UA Loose Routing: Alternative using P-Called-Party X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0058088622==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0058088622== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD96.56901CDD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD96.56901CDD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, Is there a reason why the usage of P-Called-Party is not listed as an alternative solution in chapter 4? Regards, Christer ------_=_NextPart_001_01C7AD96.56901CDD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UA Loose Routing: Alternative using P-Called-Party

Hi Jonathan,

Is there a reason why the usage of = P-Called-Party is not listed as an alternative solution in chapter = 4?

Regards,

Christer

------_=_NextPart_001_01C7AD96.56901CDD-- --===============0058088622== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0058088622==-- From sip-bounces@ietf.org Wed Jun 13 04:58:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyOgU-00077j-0Y; Wed, 13 Jun 2007 04:58:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyOgS-00077e-Rk for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 04:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyOgS-00077W-GI for sip@ietf.org; Wed, 13 Jun 2007 04:58:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyOgQ-0006xd-VP for sip@ietf.org; Wed, 13 Jun 2007 04:58:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7FA9F210D9; Wed, 13 Jun 2007 10:58:30 +0200 (CEST) X-AuditID: c1b4fb3e-b0678bb0000007e1-c3-466fb1b642f2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6781A210A4; Wed, 13 Jun 2007 10:58:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:58:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Issue #1: Backwards compatibility Date: Wed, 13 Jun 2007 10:58:29 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> In-Reply-To: <466F5E26.2000709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Issue #1: Backwards compatibility thread-index: AcetZ0DOqB3YjaOAQLqat86xRdJTpgAMH2Ew References: <466F5E26.2000709@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 08:58:30.0116 (UTC) FILETIME=[0359B240:01C7AD99] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, At least with existing MGCs you will have backward compability issues. MGCs normally route SIP-to-ISUP calls based on the Request-URI, and if = the Request-URI contains e.g. a sos servicetype URN, or a 800 service = number, the MGC will not be able to route on those. Regards, Christer =20 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 13. kes=E4kuuta 2007 6:02 > To: IETF SIP List > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility >=20 > I've recently revised my draft on UA loose routing. You can=20 > pick it up here: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > se-route-01.txt >=20 > This draft is meant to fulfill one of our charter items: > Feb 2008 Delivering request-URI and parameters=20 > to UAS via proxy to=20 > IESG (PS) >=20 > As folks may recall, the GRUU spec used to have these things=20 > called grids, which allowed a UA to add its own parameters to=20 > the GRUU before handing it out. Several GRUU revisions back,=20 > this function got yanked because it was recognized that the=20 > problem was more general than GRUU, and would be useful for=20 > AOR as well. >=20 > Two IETFs back I presented this draft briefly during a SIP session.=20 > There was a lot of interest and people liked it=20 > architecturally, however there were two open issues that=20 > needed to get resolved. This mail is meant to start=20 > discussion on one of them - backwards compatibility. >=20 > THe mechanism basically changes the way proxies handle=20 > requests. Instead of rewriting the request URI for=20 > out-of-dialog requests, they'll push a route header and leave=20 > the r-uri alone. This allows the original R-URI and any=20 > parameters it contains to get delivered to the UAS. >=20 > So, the main issue is, what kinds of backwards compatibility=20 > problems will this cause. The draft provides a basic=20 > mechanism whereby a UA includes an option tag in the=20 > REGISTER, and the registrar indicates that it is using this=20 > mechanism or not. So we can negotiate this between a UA and=20 > registrar easily. Now, the problem is with intermediate=20 > proxies. If there is an edge proxy between the UA and its=20 > registrar, it will now see requests targeted to the UA, which=20 > contain a Route header beyond itself, even though it thinks=20 > its the edge proxy and the last point of contact before the=20 > UA. Technically, if this edge proxy is compliant to rfc3261=20 > it would work. However, the question is whether proxies in=20 > the wild would properly work in this case. >=20 > If folks can comment based on their own products, or their=20 > experiences, on whether they think this would work, or=20 > concerns they have, that would be great. THere are solutions=20 > that would allow us to disable the mechanism when=20 > intermediate proxies don't support it, but they are more=20 > complex and I'd rather avoid it. >=20 > THanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 05:26:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyP7S-0005Wp-HY; Wed, 13 Jun 2007 05:26:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyP7Q-0005VP-F6 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 05:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyP7Q-0005VG-5L for sip@ietf.org; Wed, 13 Jun 2007 05:26:24 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyP7O-0007U3-EQ for sip@ietf.org; Wed, 13 Jun 2007 05:26:24 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CD1252122F; Wed, 13 Jun 2007 11:26:21 +0200 (CEST) X-AuditID: c1b4fb3e-b1e7bbb0000007e1-d7-466fb83dc479 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C11B0211F8; Wed, 13 Jun 2007 11:26:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 11:26:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Wed, 13 Jun 2007 11:26:20 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> In-Reply-To: <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcetL+i2JVVDWMMqRXeuHv/n+CiQVAAAwO2A References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> From: "Christer Holmberg (JO/LMF)" To: "Dean Willis" X-OriginalArrivalTime: 13 Jun 2007 09:26:21.0090 (UTC) FILETIME=[E7541820:01C7AD9C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Dean, Thanks for the document. I have read it before, but had forgotten about = it. Now, the first issue is how we know that the receiver supports the = Content-Type of the body sent in INFO. There are ways to solve that, and = it is not an INFO specific problem. The second issue is regarding the "SIP protocol rules", and I guess that = is one thing which causes confusion.=20 For example, if someone wants to send a DTMF tone he sends an INFO with = the DTMF tone. The receiver will determine whether it's needed for = anything (e.g. a robot asking for your PIN code) or not (e.g. if you're = talking to a person and pressed a button by misstake). What "SIP = protocol rules" do you need for that? The application will determine = what/if it does with the received information. Regards, Christer =20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 12. kes=E4kuuta 2007 23:25 > To: Christer Holmberg (JO/LMF) > Cc: SIP IETF > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > On Jun 12, 2007, at 8:53 AM, Christer Holmberg (JO/LMF) wrote: >=20 > > > >> If you are aiming towards a solution that keeps INFO for=20 > more usages,=20 > >> I would say that we need to resolve this issue first. > > > > I am just trying to figure out what the problem really is. >=20 > This is ancient, badly written in a hurry, and full of=20 > errors, but it might help: >=20 > http://www.softarmor.com/wgdb/docs/draft-willis-sip-infopackage-00.txt >=20 > -- > Dean >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 05:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyPEV-0002tf-85; Wed, 13 Jun 2007 05:33:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyPET-0002tW-Jk for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 05:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyPET-0002tO-AA for sip@ietf.org; Wed, 13 Jun 2007 05:33:41 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyPER-0008Us-N2 for sip@ietf.org; Wed, 13 Jun 2007 05:33:41 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E072E20048; Wed, 13 Jun 2007 11:33:38 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-52-466fb9f2df26 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BBE4D20042; Wed, 13 Jun 2007 11:33:38 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 11:33:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Wed, 13 Jun 2007 11:33:35 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CE52C@esealmw113.eemea.ericsson.se> In-Reply-To: <0E48B768805E4D44A70709C8AE09209097EC4B@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcetEezuUEeXdiLcQeOEPDB2ihH/kQAI4bFQABn1SSA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <466EDBEF.5040406@mailvision.com> <0E48B768805E4D44A70709C8AE09209097EC4B@EMAILEMEA3.jnpr.net> From: "Christer Holmberg (JO/LMF)" To: "Gilad Shaham" , "Diego B" X-OriginalArrivalTime: 13 Jun 2007 09:33:38.0248 (UTC) FILETIME=[EBE51C80:01C7AD9D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: sip@ietf.org, Steve Langstaff , "Rafferty, James" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >In my opinion, content-type is not good enough. What would=20 >one do if it is Multipart-Mixed? >We are talking about something general, right? What if the=20 >same content type is to be used for 2 different info usages? The application you're currently using should know what to do with it. >Christer asked if there are real life problems with using=20 >INFO for DTMF, I think it's one of the problems today with=20 >INFO in general. I'm sure it can be solved (e.g., the old=20 >draft Dean sent), but it still requires change in the spec. What real-life problems are there with using INFO for DTMF? Regards, Christer > > -----Original Message----- > > From: Diego B [mailto:diegob@mailvision.com] > > Sent: Tuesday, June 12, 2007 8:46 PM > > To: Gilad Shaham > > Cc: Christer Holmberg (JO/LMF); sip@ietf.org; Rafferty,=20 > James; Steve=20 > > Langstaff > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > > Inline > >=20 > > Gilad Shaham wrote: > > > Hi, > > > > > > Here is another major problem with INFO - there is no header that > states > > > the purpose of INFO. > > > > > If the conte-type is correct, the payload is a DTMF digit. No needs > for > > a special header. > > > The event header in subscriptions helps identify an event package. > > > Therefore an implementation can easily detect if this=20 > event package > is > > > supported or not. > > You can state in the Accept header that you support the content-type > for > > the DTMF paylod ( application/dtmf or application/dtmf-relay ) > > > With INFO it is much harder to detect the purpose of this INFO=20 > > > message. Currently AFAIK the content-type in INFO > implicitly > > > denotes this. > > > > > > > > So, why is harder ? > > > If you are aiming towards a solution that keeps INFO for more > usages, I > > > would say that we need to resolve this issue first. > > > > > > > > I do not see any issue here > > > I also think it would be a burden on implementors to do both KPML > and > > > INFO. Wouldn't it be easier for the implementors that did INFO to > switch > > > to KPML instead of the entire industry doing both? > > > > > > > > INFO is very easy to implement. So I dont't see any problem to keep > the > > INFO implementation > > until KPML is adopted. Or maybe keep both. > > > Gilad > > > > > > > > Diego B > > >> -----Original Message----- > > >> From: Christer Holmberg (JO/LMF) > > >> > > > [mailto:christer.holmberg@ericsson.com] > > > > > >> Sent: Tuesday, June 12, 2007 3:56 PM > > >> To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer > Dawkins; > > >> Robert Sparks; Jonathan Rosenberg > > >> Cc: sip@ietf.org > > >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog > usage? > > >> > > >> > > >> Hi, > > >> > > >> > > >>>> Are we aware of real-life problems with using INFO for DTMF (or > > >>>> > > >> whatever > > >> > > >>>> else it's used for)? People have been doing it for a=20 > while (if we > > >>>> > > >> wanted > > >> > > >>>> to restrict something, it should have been done years ago...), > it's > > >>>> fairly simple to implement - and it seems to work. > > >>>> > > >>> Do we need DTMF via INFO for some kind of functionality KPML (or > RFC > > >>> 2833) does not provide? I'm not aware of such a case. > > >>> > > >> Regarding 2833, I guess the main idea of sending DTMFs=20 > out-of-band > (no > > >> matter if you use INFO or something else) is when you=20 > send them to > an > > >> entity which does not have media access. > > >> > > >> > > >>> One description of a problem with INFO can be found in this > > >>> > > > historical > > > > > >>> chat: > > >>> > http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html > > >>> > > >>> The explanation from the expired draft is as follows: > > >>> > > >>> Under this proposal, a User Agent MUST NOT send=20 > signaled digits or=20 > > >>> telephone-events using the INFO method if the event was ever=20 > > >>> represented as a tone (as media). Only signals=20 > originated as pure=20 > > >>> signaling MAY generate an INFO method. > > >>> Failure to heed this requirement will result in=20 > double-detection=20 > > >>> of digits/events. > > >>> > > >>> If INFO is used incorrectly by a pair of PSTN gateways (for=20 > > >>> example), the source gateway may detect a digit, send an INFO=20 > > >>> request which is lost, and retransmit that request. The target=20 > > >>> gateway would send the original in-band tone to the=20 > PSTN when the=20 > > >>> audio media arrives, later when the INFO arrives, the target=20 > > >>> gateway would render the same tone again. > > >>> It is quite likely that the INFO will arrive after the=20 > media tone=20 > > >>> has been played (especially if multiple intermediaries are=20 > > >>> involved); the same digit would be played out again and=20 > this will=20 > > >>> frequently cause systems in the PSTN to detect the same digit=20 > > >>> signaled twice. > > >>> > > >> You can always mess up if you use things incorrectly. I=20 > don't think > > >> > > > that > > > > > >> is INFO specific. > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >> > > >>> > > >>> > > >>> > > >>>> The only problem is that much of the INFO usages are=20 > not defined > > >>>> > > > in > > > > > >>>> RFCs, but that's not always the fault of the implementors... > > >>>> > > >>> I think the implementors knew this was not standard or=20 > at most in=20 > > >>> very early draft mode when they implemented it. > > >>> > > >>> > > >>>> Regards, > > >>>> > > >>>> Christer > > >>>> > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 06:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQFv-0000H7-Kb; Wed, 13 Jun 2007 06:39:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyQFt-0000Gy-L9 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 06:39:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyQFt-0000Gk-B1 for sip@ietf.org; Wed, 13 Jun 2007 06:39:13 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyQFs-0003n1-Mk for sip@ietf.org; Wed, 13 Jun 2007 06:39:13 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5DAcll4007239 for ; Wed, 13 Jun 2007 05:39:12 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 05:39:04 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 12:39:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 12:39:01 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C9556@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-answermode Thread-Index: Acetpw4CnOQ+4mApSiW6oUtAdANdKA== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 10:39:01.0527 (UTC) FILETIME=[0E59FA70:01C7ADA7] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Subject: [Sip] Publication request for draft-ietf-sip-answermode X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I have just requested publication of: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-04.txt The next stage for submitting comments is therefore the IESG last call. The PROTO writeup submitted with the publication request is as follows. Please feel free to respond if you consider any of the information incorrect. Regards Keith ------------------------------------------------------------------------ --- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip- answermode-04.txt: "Requesting Answering Modes for the Session Initiation=20 Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: - draft-allen-sipping-poc-p-headers-00 created November 2004, expired=20 May 2005. - draft-allen-sipping-poc-p-headers-01.txt created February 7th 2005,=20 expired August 8th 2005 (split into two drafts, the one below and a=20 separate P-header draft which remained in SIPPING). - draft-willis-sip-answeralert-00 created June 14th 2005, expired=20 December 16th 2005. Discussed at IETF#63. - draft-willis-sip-answeralert-01 created August 31st 2005, expired=20 March 4th 2006. Discussed at IETF#64. - draft-ietf-sip-answermode-00 created December 14th 2005, expired June=20 17th 2006. - draft-ietf-sip-answermode-01 created April 3rd 2006, expired October=20 3rd 2006. - draft-ietf-sip-answermode-02 created March 4th 2007, expires=20 September 5th 2007. - draft-ietf-sip-answermode-03 created May 10th 2007, expires November=20 11th 2007. - draft-ietf-sip-answermode-04 created June 12th 2007, expires December=20 14th 2007. WGLC was initiated on draft-ietf-sip-answermode-00 on 23rd February 2006 with=20 comments requested by 15th March 2006. Reviews were conducted by and comments received from Hans Persson, Jeroen=20 van Bemmel, and Paul Kyzivat. At least 5 other people commented on earlier=20 versions of the document. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? The document defines mechanisms that are entirely internal to the Session=20 Initiation Protocol (SIP). The document shepherd considers that no external=20 review from an external specialist is necessary. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. There have been no IPR disclosures on this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Section 1 of the document represents the background to the initiation of this work, and details a strong requirement from OMA for a SIP solution in=20 this area. However uses in the SIP WG were found for a more general=20 mechanism. Less generic parts of the original proposal form the basis of a=20 separate draft draft-allen-sipping-poc-p-answer-state-header-04 being=20 progressed under the rules of RFC 3427 as a P-header. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines new SIP headers and a new SIP option tag, these=20 have been performed as a SIP working group item, and therefore this draft is=20 in conformance with RFC 3427. For ID-NITS (idnits 2.04.09) the checks report no errors. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are now published RFCs. There are=20 no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Section 8 of the document contains the IANA considerations. Section 8.1 of the document registers the two new SIP header fields that are=20 defined elsewhere in the document. This registration is consistent with RFC=20 3968 which defines the registry and is also consistent with the current=20 format of the registry. Section 8.2 of the document registers two new header field parameters for=20 the new Answer-Mode header field, and which are defined elsewhere in the document. Section 8.2 of the document also registers the same two new header=20 field parameters for the new Priv-Answer-Mode header field, and again these=20 are defined elsewhere in the document. This registration is consistent with=20 RFC 3968 which defines the registry and is also consistent with the current=20 format of the registry. Section 8.3 of the document registers a new option-tag; the new option-tag=20 is defined elsewhere in the document. This registration is consistent with=20 RFC 3968 which defines the registry and is also consistent with the current=20 format of the registry. It has been checked that there are no other protocol elements requiring=20 registration. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Section 3 of the document specifies the new headers in ABNF. This ABNF=20 passes the checks in http://rtg.ietf.org/~fenner/abnf.cgi. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are .' Technical Summary This document defines extends SIP with two header fields and associated=20 option tags that can be used in INVITE requests to convey the requester's=20 preference for user-interface handling related to answering of that request. =20 The first header, "Answer-Mode", expresses a preference as to whether the=20 target node's user interface waits for user input before accepting the=20 request or instead accepts the request without waiting on user input. The=20 second header, "Priv-Answer-Mode" is similar to the first, except that it=20 requests administrative-level access and has consequent additional=20 authentication and authorization requirements. These behaviors have=20 applicability to applications such as Push-to-Talk and to diagnostics like=20 loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. Working Group Summary There is consensus in the working group to publish this document. The=20 proposal was originally submitted as a P-header, but it was decided that this aspect should be brought out and made generally applicable to all SIP=20 implementations. Early concerns about the possibility to use the header as a=20 means of eavesdropping have been addressed in the security considerations. Document Quality There has been no indication of implementation. The document has been=20 required in support of the OMA PoC feature, and it can be assumed that there=20 have been implementations of the OMA work that have therefore used this=20 feature. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. The IANA Expert(s) for the registries in=20 this document are . ------------------------------------------------------------------------ ----- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 07:32:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyR5R-0003Vl-9z; Wed, 13 Jun 2007 07:32:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyR5P-0003RC-3O for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 07:32:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyR5O-0003QN-Ke for sip@ietf.org; Wed, 13 Jun 2007 07:32:26 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyR5M-0001hf-NE for sip@ietf.org; Wed, 13 Jun 2007 07:32:26 -0400 X-AuditID: c26e2f18-000012f000001c9c-39-466fd5af0e53 Received: from veyron.eu.tieto.com ([194.110.47.230]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:31:59 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:32:19 +0300 Received: from 10.15.1.83 ([10.15.1.83]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Jun 2007 11:32:19 +0000 Received: from ww003517.tieto.eu.com by email2.tietoenator.com; 13 Jun 2007 13:32:58 +0200 From: Martin Hynar To: aki.niemi@nokia.com Date: Wed, 13 Jun 2007 13:32:35 +0200 Message-Id: <1181734355.6595.18.camel@ww003517.tieto.eu.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 13 Jun 2007 11:32:19.0639 (UTC) FILETIME=[80932470:01C7ADAE] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: sip@ietf.org Subject: [Sip] Several notes to entity-tags for SIP Events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123819553==" Errors-To: sip-bounces@ietf.org --===============1123819553== Content-Type: multipart/alternative; boundary="=-jUUiff3qqMvAxXiBqRwg" --=-jUUiff3qqMvAxXiBqRwg Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, I read through the draft sip-subnot-etags-00 and I found several issues that needs to be clarified. 1. typo in introduction In sentence "Typically, a SUBSCRIBE request is issued whenever a subscription is installed, periodically refreshed or terminated." shall be probably "NOTIFY". 2. some kind of misleading in text when talking about SIP PUBLISH message as an example of entity tags usage. When talking about PUBLISH I think, there is slightly different usage scenario. In response to initial PUBLISH message, server generates entity tag. Client is mandated to use this entity tag if she wants to change state of that particular presence source. If this entity tag is not used, PUBLISH message installs new presence source and not overwrites the former state. For purposes of presence notifications, these publications are then composed. This usage is a bit different that supposed for SUBSCRIBE messages, The text evokes feeling of something different. 3. What is exactly meant with "Meta-information-check"? What is this meta information. 4. Besides RLS subscriptions there is one more problem, the subscriptions to changes in documents. So extend the problem also on notification about changes in multiple documents. 5. In my mind, there popped up an idea to move the SIP-Etag into the response to SUBSCRIBE message. This way client can be informed about the entity tag also without sending the NOTIFY message at all. Have you considered this possibility? 6. What about situation when e.g. presentity has no presence document installed and some body subscribes her. The the notifier sends empty document, wouldn't be there some special handling? E.g. no entity tag. br, Martin +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying 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. --=-jUUiff3qqMvAxXiBqRwg Content-Type: text/html; charset=utf-8 Hello,

I read through the draft sip-subnot-etags-00 and I found several issues that needs to be clarified.


1. typo in introduction
In sentence "Typically, a SUBSCRIBE request is issued whenever a subscription is installed, periodically refreshed or terminated." shall be probably "NOTIFY".

2. some kind of misleading in text when talking about SIP PUBLISH message as an example of entity tags usage. When talking about PUBLISH I think, there is slightly different usage scenario. In response to initial PUBLISH message, server generates entity tag. Client is mandated to use this entity tag if she wants to change state of that particular presence source. If this entity tag is not used, PUBLISH message installs new presence source and not overwrites the former state. For purposes of presence notifications, these publications are then composed. This usage is a bit different that supposed for SUBSCRIBE messages, The text evokes feeling of something different.

3. What is exactly meant with "Meta-information-check"? What is this meta information.

4. Besides RLS subscriptions there is one more problem, the subscriptions to changes in documents. So extend the problem also on notification about changes in multiple documents.

5. In my mind, there popped up an idea to move the SIP-Etag into the response to SUBSCRIBE message. This way client can be informed about the entity tag also without sending the NOTIFY message at all. Have you considered this possibility?

6. What about situation when e.g. presentity has no presence document installed and some body subscribes her. The the notifier sends empty document, wouldn't be there some special handling? E.g. no entity tag.

br, Martin

+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying 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.
--=-jUUiff3qqMvAxXiBqRwg-- --===============1123819553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1123819553==-- From sip-bounces@ietf.org Wed Jun 13 08:04:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRal-0006QD-DC; Wed, 13 Jun 2007 08:04:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyRak-0006P7-4s for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRaj-0006Oi-Ka for sip@ietf.org; Wed, 13 Jun 2007 08:04:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRai-0006Hq-6d for sip@ietf.org; Wed, 13 Jun 2007 08:04:49 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2007 08:04:48 -0400 X-IronPort-AV: i="4.16,416,1175486400"; d="scan'208"; a="123467924:sNHT53513774" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5DC4lr0014047; Wed, 13 Jun 2007 08:04:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5DC4hBe019032; Wed, 13 Jun 2007 12:04:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 08:03:59 -0400 Received: from [10.86.242.65] ([10.86.242.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 08:03:59 -0400 Message-ID: <466FDD2B.9050907@cisco.com> Date: Wed, 13 Jun 2007 08:03:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Jun 2007 12:03:59.0450 (UTC) FILETIME=[ECF34BA0:01C7ADB2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4244; t=1181736287; x=1182600287; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20UA=20Loose=20Routing=20Issue=20#1=3A=20Backwa rds=20compatibility |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=ZkSXOFjwAA9r9z0HQ7mn9I1IKpNzuY+cnkWYxFhXdQc=; b=z1oOoH/P9R0I55LBhNfn+UT4qbqlDweq7GKrsXhSuZIPTKwNO7BCfvET2w28ivueTZk6BbKS jqTqYfUqGgKFGZXp7GiAfbCiJtA3ERuMIp9/miFMB33Xso8O6PUKaPaW; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You have an MGC that registers? If so, it can avoid this problem by not using the new option when registering. This is *optional* behavior. Paul Christer Holmberg (JO/LMF) wrote: > Hi, > > At least with existing MGCs you will have backward compability issues. > > MGCs normally route SIP-to-ISUP calls based on the Request-URI, and if the Request-URI contains e.g. a sos servicetype URN, or a 800 service number, the MGC will not be able to route on those. > > Regards, > > Christer > > > > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] >> Sent: 13. kesäkuuta 2007 6:02 >> To: IETF SIP List >> Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility >> >> I've recently revised my draft on UA loose routing. You can >> pick it up here: >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo >> se-route-01.txt >> >> This draft is meant to fulfill one of our charter items: >> Feb 2008 Delivering request-URI and parameters >> to UAS via proxy to >> IESG (PS) >> >> As folks may recall, the GRUU spec used to have these things >> called grids, which allowed a UA to add its own parameters to >> the GRUU before handing it out. Several GRUU revisions back, >> this function got yanked because it was recognized that the >> problem was more general than GRUU, and would be useful for >> AOR as well. >> >> Two IETFs back I presented this draft briefly during a SIP session. >> There was a lot of interest and people liked it >> architecturally, however there were two open issues that >> needed to get resolved. This mail is meant to start >> discussion on one of them - backwards compatibility. >> >> THe mechanism basically changes the way proxies handle >> requests. Instead of rewriting the request URI for >> out-of-dialog requests, they'll push a route header and leave >> the r-uri alone. This allows the original R-URI and any >> parameters it contains to get delivered to the UAS. >> >> So, the main issue is, what kinds of backwards compatibility >> problems will this cause. The draft provides a basic >> mechanism whereby a UA includes an option tag in the >> REGISTER, and the registrar indicates that it is using this >> mechanism or not. So we can negotiate this between a UA and >> registrar easily. Now, the problem is with intermediate >> proxies. If there is an edge proxy between the UA and its >> registrar, it will now see requests targeted to the UA, which >> contain a Route header beyond itself, even though it thinks >> its the edge proxy and the last point of contact before the >> UA. Technically, if this edge proxy is compliant to rfc3261 >> it would work. However, the question is whether proxies in >> the wild would properly work in this case. >> >> If folks can comment based on their own products, or their >> experiences, on whether they think this would work, or >> concerns they have, that would be great. THere are solutions >> that would allow us to disable the mechanism when >> intermediate proxies don't support it, but they are more >> complex and I'd rather avoid it. >> >> THanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.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 sip-bounces@ietf.org Wed Jun 13 08:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRiD-0002ev-J0; Wed, 13 Jun 2007 08:12:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyRiA-0002QE-MK for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRi9-0002A6-2C for sip@ietf.org; Wed, 13 Jun 2007 08:12:29 -0400 Received: from lohi.tutpro.com ([192.98.100.2] helo=tutpro.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRhk-0001jq-6a for sip@ietf.org; Wed, 13 Jun 2007 08:12:06 -0400 Received: from localhost (localhost [127.0.0.1]) by tutpro.com (Postfix) with ESMTP id 2D8761EC65D; Wed, 13 Jun 2007 15:12:03 +0300 (EEST) Received: from tutpro.com ([127.0.0.1]) by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhh3Skx83HUK; Wed, 13 Jun 2007 15:12:01 +0300 (EEST) Received: from taimen (telomeres241.gprs.dnafinland.fi [62.78.111.241]) by tutpro.com (Postfix) with ESMTP; Wed, 13 Jun 2007 15:12:01 +0300 (EEST) Received: by taimen (Postfix, from userid 1000) id 27090AC050; Wed, 13 Jun 2007 15:11:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18031.57102.133329.584189@tutpro.com> Date: Wed, 13 Jun 2007 15:11:58 +0300 To: Jonathan Rosenberg Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility In-Reply-To: <466F5E26.2000709@cisco.com> References: <466F5E26.2000709@cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 From: jh@tutpro.com (Juha Heinanen) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg writes: > If folks can comment based on their own products, or their experiences, > on whether they think this would work, or concerns they have, that would > be great. jonathan, [open]ser proxies have a large number of functions to examine and manipulate request uri. it would mean lots of coding work to make all same functions apply to an uri in the route header. so i don't like this change at all. why can't you say that when proxies rewrite request uri, they need to leave parameters (or at least some parameters) alone? or, why can't you say that if a proxy rewrites request uri, it needs to push the original request uri into some new header unless this new header already exists? -- 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 sip-bounces@ietf.org Wed Jun 13 08:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRk8-0004Dw-PH; Wed, 13 Jun 2007 08:14:32 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyRk6-000496-HT for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRiB-0002A6-Ck for sip@ietf.org; Wed, 13 Jun 2007 08:12:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRfx-00015V-9Z for sip@ietf.org; Wed, 13 Jun 2007 08:10:13 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BAF4C200DC; Wed, 13 Jun 2007 14:10:12 +0200 (CEST) X-AuditID: c1b4fb3e-b1e7bbb0000007e1-68-466fdea45123 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9A0C42009C; Wed, 13 Jun 2007 14:10:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:10:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Issue #1: Backwards compatibility Date: Wed, 13 Jun 2007 14:10:11 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CEB80@esealmw113.eemea.ericsson.se> In-Reply-To: <466FDD2B.9050907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Issue #1: Backwards compatibility thread-index: Acetswt6KQVDcPrVTnqfJ/g2laaRSAAAJnww References: <466F5E26.2000709@cisco.com> <7374777208BDC7449D5620EF94232567052CE377@esealmw113.eemea.ericsson.se> <466FDD2B.9050907@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 13 Jun 2007 12:10:12.0160 (UTC) FILETIME=[CB1A5400:01C7ADB3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >You have an MGC that registers? >=20 >If so, it can avoid this problem by not using the new option=20 >when registering. This is *optional* behavior. Correct. My misstake. Regards, Christer > Christer Holmberg (JO/LMF) wrote: > > Hi, > >=20 > > At least with existing MGCs you will have backward=20 > compability issues. > >=20 > > MGCs normally route SIP-to-ISUP calls based on the=20 > Request-URI, and if the Request-URI contains e.g. a sos=20 > servicetype URN, or a 800 service number, the MGC will not be=20 > able to route on those. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > >> Sent: 13. kes=E4kuuta 2007 6:02 > >> To: IETF SIP List > >> Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility > >> > >> I've recently revised my draft on UA loose routing. You=20 > can pick it=20 > >> up here: > >> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > >> se-route-01.txt > >> > >> This draft is meant to fulfill one of our charter items: > >> Feb 2008 Delivering request-URI and parameters=20 > >> to UAS via proxy to > >> IESG (PS) > >> > >> As folks may recall, the GRUU spec used to have these=20 > things called=20 > >> grids, which allowed a UA to add its own parameters to the GRUU=20 > >> before handing it out. Several GRUU revisions back, this=20 > function got=20 > >> yanked because it was recognized that the problem was more general=20 > >> than GRUU, and would be useful for AOR as well. > >> > >> Two IETFs back I presented this draft briefly during a SIP=20 > session.=20 > >> There was a lot of interest and people liked it architecturally,=20 > >> however there were two open issues that needed to get=20 > resolved. This=20 > >> mail is meant to start discussion on one of them - backwards=20 > >> compatibility. > >> > >> THe mechanism basically changes the way proxies handle requests.=20 > >> Instead of rewriting the request URI for out-of-dialog requests,=20 > >> they'll push a route header and leave the r-uri alone. This allows=20 > >> the original R-URI and any parameters it contains to get=20 > delivered to=20 > >> the UAS. > >> > >> So, the main issue is, what kinds of backwards=20 > compatibility problems=20 > >> will this cause. The draft provides a basic mechanism whereby a UA=20 > >> includes an option tag in the REGISTER, and the registrar=20 > indicates=20 > >> that it is using this mechanism or not. So we can negotiate this=20 > >> between a UA and registrar easily. Now, the problem is with=20 > >> intermediate proxies. If there is an edge proxy between the UA and=20 > >> its registrar, it will now see requests targeted to the UA, which=20 > >> contain a Route header beyond itself, even though it=20 > thinks its the=20 > >> edge proxy and the last point of contact before the UA.=20 > Technically,=20 > >> if this edge proxy is compliant to rfc3261 it would work. However,=20 > >> the question is whether proxies in the wild would properly work in=20 > >> this case. > >> > >> If folks can comment based on their own products, or their=20 > >> experiences, on whether they think this would work, or=20 > concerns they=20 > >> have, that would be great. THere are solutions that would=20 > allow us to=20 > >> disable the mechanism when intermediate proxies don't=20 > support it, but=20 > >> they are more complex and I'd rather avoid it. > >> > >> THanks, > >> Jonathan R. > >> --=20 > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ=20 > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: =20 > (973) 952-5050 > >> http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > >> http://www.cisco.com > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >> > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 08:45:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySDz-0003ud-G4; Wed, 13 Jun 2007 08:45:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HySDx-0003lG-Kj for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:45:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySDx-0003iy-9i for sip@ietf.org; Wed, 13 Jun 2007 08:45:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HySDr-0004td-26 for sip@ietf.org; Wed, 13 Jun 2007 08:45:21 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5DE1B20FD5; Wed, 13 Jun 2007 14:45:14 +0200 (CEST) X-AuditID: c1b4fb3e-b167abb0000007e1-a4-466fe6da1f04 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3E02420427; Wed, 13 Jun 2007 14:45:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:45:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Issue #1: Backwards compatibility - Path Date: Wed, 13 Jun 2007 14:45:12 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CECE8@esealmw113.eemea.ericsson.se> In-Reply-To: <466F5E26.2000709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Issue #1: Backwards compatibility - Path thread-index: AcetZ0DOqB3YjaOAQLqat86xRdJTpgATachQ References: <466F5E26.2000709@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 12:45:13.0776 (UTC) FILETIME=[AFC37B00:01C7ADB8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, Another thing to keep in mind is that when the Path header is used, the = generated Route (used from the home proxy towards the UE) will not be = identical to the Path. Route =3D Path + pushed Route Now, I don't know whether RFC3327 says that the Route MUST be identical = to the Path it's based on, or whether it's allowed to add Route(s) in = addition to those based on the Path, but there could be intermediates = that do some kind of checking. Regards, Christer > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: 13. kes=E4kuuta 2007 6:02 > To: IETF SIP List > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility >=20 > I've recently revised my draft on UA loose routing. You can=20 > pick it up here: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > se-route-01.txt >=20 > This draft is meant to fulfill one of our charter items: > Feb 2008 Delivering request-URI and parameters=20 > to UAS via proxy to=20 > IESG (PS) >=20 > As folks may recall, the GRUU spec used to have these things=20 > called grids, which allowed a UA to add its own parameters to=20 > the GRUU before handing it out. Several GRUU revisions back,=20 > this function got yanked because it was recognized that the=20 > problem was more general than GRUU, and would be useful for=20 > AOR as well. >=20 > Two IETFs back I presented this draft briefly during a SIP session.=20 > There was a lot of interest and people liked it=20 > architecturally, however there were two open issues that=20 > needed to get resolved. This mail is meant to start=20 > discussion on one of them - backwards compatibility. >=20 > THe mechanism basically changes the way proxies handle=20 > requests. Instead of rewriting the request URI for=20 > out-of-dialog requests, they'll push a route header and leave=20 > the r-uri alone. This allows the original R-URI and any=20 > parameters it contains to get delivered to the UAS. >=20 > So, the main issue is, what kinds of backwards compatibility=20 > problems will this cause. The draft provides a basic=20 > mechanism whereby a UA includes an option tag in the=20 > REGISTER, and the registrar indicates that it is using this=20 > mechanism or not. So we can negotiate this between a UA and=20 > registrar easily. Now, the problem is with intermediate=20 > proxies. If there is an edge proxy between the UA and its=20 > registrar, it will now see requests targeted to the UA, which=20 > contain a Route header beyond itself, even though it thinks=20 > its the edge proxy and the last point of contact before the=20 > UA. Technically, if this edge proxy is compliant to rfc3261=20 > it would work. However, the question is whether proxies in=20 > the wild would properly work in this case. >=20 > If folks can comment based on their own products, or their=20 > experiences, on whether they think this would work, or=20 > concerns they have, that would be great. THere are solutions=20 > that would allow us to disable the mechanism when=20 > intermediate proxies don't support it, but they are more=20 > complex and I'd rather avoid it. >=20 > THanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 08:48:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySGh-0005u7-Jm; Wed, 13 Jun 2007 08:48:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HySGf-0005u1-SL for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySGf-0005tt-Is for sip@ietf.org; Wed, 13 Jun 2007 08:48:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HySGe-0005Uc-5M for sip@ietf.org; Wed, 13 Jun 2007 08:48:09 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA86621225; Wed, 13 Jun 2007 14:48:07 +0200 (CEST) X-AuditID: c1b4fb3e-b1e7bbb0000007e1-1f-466fe7878236 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A0193211FD; Wed, 13 Jun 2007 14:48:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:48:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Issue #1: Backwards compatibility Date: Wed, 13 Jun 2007 14:48:06 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CED01@esealmw113.eemea.ericsson.se> In-Reply-To: <18031.57102.133329.584189@tutpro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Issue #1: Backwards compatibility thread-index: AcettC3vcH7tbewsR5GsOyrnZnko1wABM2aQ References: <466F5E26.2000709@cisco.com> <18031.57102.133329.584189@tutpro.com> From: "Christer Holmberg (JO/LMF)" To: "Juha Heinanen" , "Jonathan Rosenberg" X-OriginalArrivalTime: 13 Jun 2007 12:48:06.0922 (UTC) FILETIME=[16F776A0:01C7ADB9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>If folks can comment based on their own products, or their experiences, on whether they think this would work, or=20 >>concerns they have, that would > be great. >=20 >jonathan, >=20 >[open]ser proxies have a large number of functions to examine=20 >and manipulate request uri. it would mean lots of coding=20 >work to make all same functions apply to an uri in the route=20 >header. so i don't like this change at all. >=20 >why can't you say that when proxies rewrite request uri, they=20 >need to leave parameters (or at least some parameters) alone? >=20 >or, why can't you say that if a proxy rewrites request uri,=20 >it needs to push the original request uri into some new=20 >header unless this new header already exists? Something like P-Called-Party. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 08:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySLk-0007AX-Ld; Wed, 13 Jun 2007 08:53:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HySLi-000791-JU for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 08:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HySLi-00078t-9i for sip@ietf.org; Wed, 13 Jun 2007 08:53:22 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HySLh-00070E-0B for sip@ietf.org; Wed, 13 Jun 2007 08:53:22 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 681B320792; Wed, 13 Jun 2007 14:53:20 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-aa-466fe8c0d983 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5096E204C3; Wed, 13 Jun 2007 14:53:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:53:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 14:53:18 +0200 Message-ID: <7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> In-Reply-To: <466F5E26.2000709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA Loose Routing: Emergency example thread-index: AcetZ0DOqB3YjaOAQLqat86xRdJTpgAUip7g References: <466F5E26.2000709@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 12:53:19.0829 (UTC) FILETIME=[D1794850:01C7ADB9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Sip] UA Loose Routing: Emergency example X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, This is not very relevant to the loose route solution as such, but just a small comment on the emergency service use-case. I am not sure whether the emergency service centers will always register, and if they don't loose route of course does not solve the problem. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 09:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTER-0004jZ-HN; Wed, 13 Jun 2007 09:49:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyTEP-0004jR-Qj for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 09:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTEP-0004jJ-HC for sip@ietf.org; Wed, 13 Jun 2007 09:49:53 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTEP-0005hb-5j for sip@ietf.org; Wed, 13 Jun 2007 09:49:53 -0400 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5DDnpFR013719 for ; Wed, 13 Jun 2007 08:49:52 -0500 (CDT) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 13 Jun 2007 08:49:51 -0500 Message-ID: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith (Keith)" To: IETF SIP List Date: Wed, 13 Jun 2007 08:28:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message x-mimeole: Produced By Microsoft Exchange V6.5 x-originalarrivaltime: 13 Jun 2007 13:28:55.0366 (UTC) FILETIME=[CA5A5E60:01C7ADBE] Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Sip] INFO usage (or not) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) We have got a number of threads floating round on INFO usage, and it would be nice to identify this into a potential body of work, and see if there is support for it. We have two previous drafts that never went anywhere, although contents of both carried support in the WG at the time: http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 The Session Initiation Protocol (SIP) INFO method defines a means for transporting mid-dialog application layer data between user agents. Its initial use was to support the transport of ISUP mid-call messages which could not be mapped to any other SIP request method. However, since its initial usage for that purpose, INFO has seen widespread abuse as a means for introducing non-standard and non-interoperable extensions to SIP. For this reason, we now believe INFO should be considered harmful, and therefore, deprecated in its current form. http://tools.ietf.org/html/draft-willis-sip-infopackage-00 The SIP INFO method (RFC 2976) establishes a method by which applications may transfer application-specific information within a SIP dialog. However, RFC 2976 does not provide a mechanism for describing and documenting an application of INFO, nor does it provide a mechanism by which applications may negotiate such uses. This document provides a framework for documenting and naming specific uses of INFO (called INFO packages), for registering those package names with IANA, and for negotiating the support for various INFO packages between applications using SIP. In the thread so far there have also been suggestions that cover: - support to mediactrl for their discussion on requirements - something for hitchhiker's guide to point to: - something that answers all the questions that recur on this list on INFO usage - "I've been getting a lot of offline questions asking for the "right" way to carry information related to the session-usage (often information that's being tunneled around from companion or gatewayed protocols)." - INVITE dialog usage only, or already covered by RFC 2976 - It would be OK with me if we ALSO had this type of guidance ("don't look HERE, look over THERE") available ("stated strongly enough in an easy to stumble across place"), but if coming up with that guidance takes more than about a week, I don't see a lot of reason to hold up on "don't go there" while we explore alternatives. - INFO and DTMF - XML payloads - But people really need is guidance on when to use INFO, when to use events, and when to use something entirely different. - identification of purpose of info (Content-Type? - impacted by multipart/mixed) - any framework for control of usages (IANA registration? - RFC 3427 update) Would anybody out there like to have a go at drafting an abstract for a potential WG deliverable (and also identifying level - Info, BCP, standards track) and submitting it to the list for discussion. Remember an abstract needs to: ------------------------------------------------------------------------ ------- Every RFC must have an Abstract section following the Copyright notice. An Abstract will typically be 5-10 lines. An Abstract of more than 20 lines is generally not acceptable. The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs. Composing a useful Abstract generally requires thought and care. Usually an Abstract should begin with a phrase like "This memo ..." or "This document ...". A satisfactory abstract can often be constructed in part from material within the Introduction section, but a good abstract will be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is tempting, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract section. An Abstract should be complete in itself; it should not contain citations unless they are completely defined within the Abstract. Abbreviations appearing in the Abstract should generally be expanded in parentheses. There is a small set of reasonable exceptions to this rule (see guidelines on abbreviations, above.) ------------------------------------------------------------------------ ------ And as such should give a clear idea of whether there is anything we should charter here or not. Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 10:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTj0-0005OJ-Vi; Wed, 13 Jun 2007 10:21:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyTj0-0005O8-BX for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 10:21:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTiz-0005O0-Rj for sip@ietf.org; Wed, 13 Jun 2007 10:21:30 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTiz-0005i1-EZ for sip@ietf.org; Wed, 13 Jun 2007 10:21:29 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5DELSe9002422; Wed, 13 Jun 2007 09:21:28 -0500 (CDT) Received: from [135.180.240.247] (volker-hopc2.dnrc.bell-labs.com [135.180.240.247]) by homail.ho.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5DELEI21723; Wed, 13 Jun 2007 10:21:14 -0400 (EDT) Message-ID: <466FFD5A.2040005@bell-labs.com> Date: Wed, 13 Jun 2007 10:21:14 -0400 From: Volker Hilt User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: simo.veikkolainen@nsn.com Subject: Re: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org simo.veikkolainen@nsn.com wrote: > Hi, > I have a couple of comments/questions on this draft. > > 3.2 Policy subscription > The MIME type defined in this draft for session-independent policies is > application/session-policy+xml. It is mentioned that "a UA compliant to > this specification MUST support the User Agent Profile Data Set for > Media Policy", which (version -04) seems to define MIME type > application/media-policy-dataset+xml. I guess the MIME types should be > the same? > Good catch. I'll change the MIME type in the framework to application/media-policy-dataset+xml. > 4.2 Overview, last sentence > It is said that "Both types of policies [applying to the offer, or both > to the offer and answer] are supported by session-specific policy > mechanism." Does this require a mechanism to indicate in the policy > whether the policy applies to offer, or both offer and answer? With this > kind of mechanism the endpoint would not have to request a policy > decision for the answer, if the policy applies only to the offer. > Yes. The policy event package supports this. > 4.3.1 Offer in request, example on page 12 > What should be the behaviour if the policy check at the end (messaages 9 > and 10) indicate that the policy was unacceptable? Should there be a > re-INVITE or UPDATE, possible triggering a similar policy checking again > in the remote end? Would it be better to always wait for the policy > decision before answering with the final response? > I think it is unlikely that a policy server would decline a session at this point since it has accepted the offer earlier. If it does occur, the correct behavior for the UA would be to terminate the session by sending a BYE. I believe section 4.4.6. covers this to some extend but maybe this needs to be made more explicit. Volker >> -----Original Message----- >> From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Sent: 22.05.2007 01:06 >> To: IETF SIP List >> Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 >> >> (As WG chair) >> >> This is to announce a Working Group Last Call on >> >> http://www.ietf.org/internet-drafts/draft-ietf-sip-session-poli >> cy-framew >> ork-01.txt >> >> The WGLC is for 3 weeks and will end on 11th June 2007. >> >> Please respond to the editor, and to the SIP mailing list with >> comments. >> >> This WGLC is being held in conjunction with the two related >> documents in the SIPPING group, see mail below: >> >> Regards >> >> Keith >> >> --------------------------------------------------------------- >> --------- >> ----------------------------- >> >> Hi all, >> >> This is to announce Working Group Last Call on the following documents: >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-po >> licy-data >> set-04.txt (Recently updated to address the merging issue >> discussed on the mailing list) >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-p >> ackage-03 >> .txt (Unchanged since prior to IETF-68) >> >> This WGLC will end on 11 June 2007. >> >> Since the WG has previously reviewed these documents, the plan >> is to keep the same set of reviewers that previously volunteered: >> Bob Penfield, Shida Schubert, Flemming Andreasen, Roni >> Even However, anyone additional that would like to volunteer >> would be appreciated to get a fresh set of eyes on the document. >> >> Feedback should be sent to the authors' email addresses (which >> is cc'ed using the tools alias in the above for your >> convenience) and please copy the SIPPING mailing list. >> >> Note: the original plan was to WGLC this set of documents >> along with the framework document that moved to SIP. So, stay >> tuned for an announcement on the SIP list of the WGLC plans >> for that document. >> >> Thanks, >> Mary >> SIPPING 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 11:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUR7-0005RI-WF; Wed, 13 Jun 2007 11:07:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyUR6-0005R9-3l for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 11:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUR5-0005R0-QL for sip@ietf.org; Wed, 13 Jun 2007 11:07:03 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUR4-0007NH-LS for sip@ietf.org; Wed, 13 Jun 2007 11:07:03 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5DF6hdM024376; Wed, 13 Jun 2007 10:06:56 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:06:02 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:06:01 -0500 Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:06:01 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 17:05:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 17:05:56 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C977E@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments on draft-ietf-sip-session-policy-framework-01 Thread-Index: AcetzFenmurG16SzQwqq50+AY6x5bg== From: "DRAGE, Keith \(Keith\)" To: "Hilt, Volker \(Volker\)" , , , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 15:05:57.0235 (UTC) FILETIME=[58751430:01C7ADCC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Cc: Subject: [Sip] WGLC comments on draft-ietf-sip-session-policy-framework-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org COMMENTS: 1) Section 4.4.7.2: A proxy MAY add the "non- cacheable" header field parameter to indicate that a UA MUST NOT cache this policy server URI. You are either mixing a proxy requirement and a UA requirement in the same sentence here, or we have one instance two many of RFC 2119 language. Either way, what we have is the wrong of writing it. 2) For reference [4] config-framework, I am missing any RFC 2119 language round it. I think we are saying "provides the only way of" rather than "provides one means of" therefore I would have expected a "MUST implement". 3) Section 4.4: If we show the table of support in methods, I would prefer we show all the current methods, and therefore show all the "-". There are other SIP documents you can use as a template. 4) Update reference [7] from RFC 2327 to RFC 4566. There does not seem to be any need to reference the older version. 5) With regard to reference [8] RFC 3264 the text: A UAC compliant to this specification MUST include a Supported header field with the option tag "policy" into all requests that can initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK requests).=20 Makes this a normative reference rather than an informative reference. 6) One of the requirements of RFC 4485 (Guidelines to SIP authors) is to clearly structure the requirements relating to each entity.=20 A) I see a mixture of requirements for UAC and policy server in section 3.2, and some of the requirements apply to both.=20 B) In section 4.4.7.1 can you move the RFC 2119 requirement to the appropriate procedures section.=20 C) The same applies for section 4.4.7.2.=20 D) Can you explain why section 3.2 and section 4.5 are so widely separated? 7) Section 3.2: The session-independent policies contained in a notification MUST represent a complete session-independent policy. Deltas to previous policies or partial policies are not supported.=20 Seems to be primarily a sending requirement (i.e. for the policy server). Please write "The policy server MUST..." and if there is a separate receiver (UAC) requirement, then draft a separate statement. 8) There are two ways of doing the requirements for security. One is to put all the RFC 2119 language relating to security in the security considerations section, which is apparently what this draft does. The other is to integrate these requirements in the procedures and reflect on the security support given by these requirements in the security considerations section. I prefer the latter - it makes it harder for an implementor to ignore the security requirements. 9) I don't like the semantics of the option tag registration. I would prefer to relate this to support of particular procedures, rather than support of the headers. Support of headers is a bit nebulous - a proxy supports it if it passes it on transparently. A UA supports it if it renders the contents to a user. 10) Can you put the appendixes at the end of the document, thereby bringing forward the references and author details. NITS: 1) For all response code usage, use the form "488 (Not Acceptable Here) response" rather than any abbreviated form on all occurrences. =09 2) There seems to be a significant usage of "it" in statements with RFC 2119 language, as in=20 =20 It SHOULD store policy server URIs in this list even if they are marked as "non- cacheable" Please use the name of entity even if it was included in the conditional at the start of the sentence, or in a previous sentence. 3) In all references made from the text, rather than statements of the form (e.g. according to [6]) Can we use either: (e.g. according to RFC 3261 [6]) Or (e.g. according to [RFC3261]) To save having to refer to the list at the end of the document. 4) Please deal with idnits as identified below: -------------------------------------------------------------------- idnits 2.04.09=20 tmp/draft-ietf-sip-session-policy-framework-01.txt: Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748: =20 ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: =20 ------------------------------------------------------------------------ ---- =3D=3D No 'Intended status' indicated for this document; assuming = Proposed Standard Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 ------------------------------------------------------------------------ ---- No issues found here. Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D Line 952 has weird spacing: '... where prox...' =3D=3D The document seems to lack the recommended RFC 2119 = boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Checking references for intended status: Proposed Standard =20 ------------------------------------------------------------------------ ---- (See RFC 3967 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '2' (No intended status found in state file of draft-ietf-sipping-policy-package) =3D=3D Outdated reference: A later version (-04) exists of draft-ietf-sipping-media-policy-dataset-02 -- Possible downref: Normative reference to a draft: ref. '3' (No intended status found in state file of draft-ietf-sipping-media-policy-dataset) =3D=3D Outdated reference: A later version (-12) exists of draft-ietf-sipping-config-framework-10 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) ------------------------------------------------------------------------ ----- 5) I suspect you will need to update the address for Jonathan Rosenberg. 6) Section 1: However, experience has shown that there is a need for SIP intermediaries to impact aspects of a session. For example, SIP may be used in a wireless network, which has limited resources for media traffic. Change "may" --> "can" Also same paragraph: Similarly, a network provider may have a service level agreement with a user that defines the set of media types a user can use.=20 Change "may" --> "can" Also section 1: Domains often enforce the session policies they have in place. For example, a domain might have a policy that disallows the use of video and may enforce this policy by dropping all packets that contain a video encoding.=20 Change "may" --> "can" And same paragraph This may lead to a malfunctioning of devices that is incomprehensible to the user. Change "may" --> "can" 7) Section 3: Session-independent policies are policies that are created independent of a session and generally apply to all sessions a user agent is setting up. They typically remain stable for a longer period of time and apply to any session set up while they are valid. However, session-independent policies may also change over time. For example, a policy that defines a bandwidth limit for a user may change during the day, defining a lower limit during peak hours and allow more bandwidth off-peak. Change "may" --> "can" twice. 8) Section 3.1 A SIP UA may receive session-independent policies from one or more policy servers. In a typical configuration, a UA receives session- independent policies from a policy server in the access or local network domain (i.e. the domain from which the UA receives IP service) and possibly the home network domain (i.e. the domain the UA registers at). The local network may have policies that support the access network infrastructure. For example, in a wireless network where bandwidth is scarce, a provider may restrict the bandwidth available to an individual user. The home network may have policies that are needed to support services or policies that reflect the service level agreement with the user. Thus, in most cases, a UA will receive session-independent policies from one or two policy servers. Change "may" --> "can" three times. 2. The policy server selects the policies that apply to this user agent. The policy server may have general policies that apply to all users or maintain separate policies for each individual user. The selected policies are returned to the user agent. 3. The policy server may update the policies, for example, when network conditions change. Change "may" --> "can" twice. 9) Section 3.2: A change in the policy may be triggered, for example, by a change in the network status, by the change in the time of day or by an update of the service level agreement with the customer. Change "may" --> "can" 10) Section 4: Session-specific policies are policies that are created specifically for one particular session of a UA. Thus, session-specific policies will typically be different for different sessions. The session- specific policies for a session may change during the course of the session. For example, a user may run out of credit during a session, which will cause the network to disallow the transmission all media streams from this point on. Change "may" --> "can" twice. 11) Section 4.1: The policy server is a separate logical entity that may be physically co-located with the proxy. The role of the policy server is to deliver session policies to UAs. The policy server receives session information from the UA, uses this information to determine the policies that apply to the session and returns these policies to the UA. The mechanism for generating policies (i.e. making policy decisions) is outside of the scope of this specification. A policy server may, for example, query an external entity to get policies or it may directly incorporate a policy decision point and generate policies locally. Change "may" --> "can" three times. And in the same section: A UA receives the URI of a policy server from a proxy. It uses this URI to contact the policy server. It provides information about the current session to the policy server and receives session policies in response. The UA may also receive policy updates from the policy server during the course of a session. Change "may" --> "can" A network may have a policy enforcement infrastructure in place. However, this specification does not make any assumptions about the enforcement of session policies and the mechanisms defined here are orthogonal a policy enforcement infrastructure. Their goal is to provide a mechanism to convey session information to a policy server and to return the policies that apply to a session to the UA. Change "may" --> "can" 12) Section 4.2: In many cases, the mechanism for session-specific policies will be used to disclose session information and return session policies. However, some scenarios may only involve the disclosure of session information to a network intermediary. If an intermediary does not intend to return a policy, it can simply accept the session as it was proposed. Similarly, some session-specific policies only apply to the offer (and therefore only require the disclosure of the offer) whereas others apply to offer and answer. Both types of policies are supported by session-specific policy mechanism. Change "may" --> "can" 13) Section 4.4.1: A UAC may receive a 488 response that contains a Policy-Contact header field. Change "may" --> "can" The token is an opaque string the UAC may have received from the policy server after contacting it. Change "may" --> "can" Note: it has been proposed to use the Policy-Id header to provide a hint for a proxy that the UAC has actually contacted the policy server. This usage also requires the policy server to return a token to the UA. In addition, the policy server needs to share valid tokens with the proxy. After receiving a request with a Policy-Id header, the proxy can determine if the token in the Policy-Id header is valid. If it is valid, the proxy knows that the UA has contacted the policy server for this session. However, it is important to note that this token does not provide any proof that the UA has actually used the policies it has received from the policy server. A malicious UA may simply contact the policy server, discard all policies it receives but still use the token in the Policy-Id header. Change "may" --> "can" Delete: "it is important to note that". In some cases, a request may traverse multiple domains with session- policies in place. Each of these domains may return a 488 response containing a policy server URI. Change "may" --> "can" twice. A UA may decide to change the session description of a session and to initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE or PRACK requests) to re-negotiate the session description.=20 Change "may" --> "can" 14) Section 4.4.2: If the local policy server URI is present in a Policy-Id header value of a request, then the proxy MUST NOT reject the request as described above (it may still reject the request for other reasons). Change "may" --> "can" 15) Section 4.4.3: A UAS may receive an INVITE, UPDATE or PRACK request (or another request that can initiate offer/answer exchanges), which contains a Policy-Contact header filed with a list of policy server URIs. Change "may" --> "can" A UAS may receive a token from a policy server via the policy channel. Since the UAS does not create a Policy-ID header, it can simply ignore this token. Change "may" --> "can" 16) Section 4.4.4: A UAC may frequently need to contact the policy server in the local domain before sending a request. To avoid the retransmission of the local policy server URI for each new request, a UA SHOULD maintain a cache that contains the URI of the local policy server. A UA may receive this URI in a Policy-Contact header of a request or a 488 response. The UA may also receive the local policy server URI through configuration, for example, via the configuration framework [4]. If a UA has received a local policy server URI through configuration and receives another local policy server URI in a Policy-Contact header, it SHOULD overwrite the configured URI with the most recent one received in a Policy-Contact header. Change "may" --> "can" three times. The UA SHOULD NOT cache policy server URIs it has received from proxies outside of the local domain. These policy servers may not be relevant for subsequent sessions, which may go to a different destination, traversing different domains. Change "may not" to "need not" Change "may" --> "can" The UA MUST NOT cache tokens it may receive from a policy server. A token is only valid for one request. Change "may" --> "can" 17) Section 4.4.6: Note: this assumes that the policy server can always respond immediately to a policy request and does not require manual intervention to create a policy. This will be the case for most policy servers. If, however, a policy server cannot respond with a policy right away, it may return a policy that temporarily denies the session and update this policy as the actual policy decision becomes available. A delay in the response from the policy server to the UA would delay the transmission of the ACK and could trigger retransmissions of the INVITE response (also see the recommendations for Flow I in [9]). Change "may" --> "can" A UA MUST inform the policy server when a session is terminated via the policy channel. This enables a policy server to free all resources it may have allocated for this session. A policy server can indicate via the policy channel that it does not need to be contacted at the end of a session. In this case, the UA SHOULD NOT inform the policy server about the termination of the session. Change "may have" --> "has" 18) Section 4.4.7.1: The value of a Policy-Id header consists of a policy server URI. A Policy-Id header value may have an optional token parameter. The token parameter contains a token the UA may receive from the policy server. =20 Change "may have" --> "can have" Change "may receive" --> "received"=20 19) Section 4.5: If the policy update causes a change in the session description of a session, the UA may need to re-negotiate the modified session description with its peer UA, for example, using a re-INVITE or UPDATE request. Change "may need" to "needs". 20 Section 5: Session policies can significantly change the behavior of a user agent and can be used by an attacker to compromise a user agent. For example, session policies can be used to prevent a user agent from successfully establishing a session (e.g. by setting the available bandwidth to zero). Such a policy can be submitted to the user agent during a session, which may cause the UA to terminate the session. Change "may cause" to "causes". A user agent transmits session information to a policy server for session-specific policies. This session information may contain sensitive data the user may not want an eavesdropper or an unauthorized policy server to see. For example, the session information may contain the encryption keys for media streams. Vice versa, session policies may also contain sensitive information about the network or service level agreements the service provider may not want to disclose to an eavesdropper or an unauthorized user agent. Change "may contain" to "can contain" twice Change "may not" to "does not" twice Change "may also" to "can also" This would impede the rendezvous between UA and policy server and, since the UA would not contact the policy server, may prevent a UA from setting up a session. Change "may" to "can" Policy servers SHOULD authenticate UAs to protect the information that is contained in a session policy. However, a policy server may also frequently encounter UAs it cannot authenticate.=20 Change "may" to "can" _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 11:59:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVFb-0002fG-0b; Wed, 13 Jun 2007 11:59:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyVFZ-0002fA-93 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 11:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyVFY-0002f2-Vf for sip@ietf.org; Wed, 13 Jun 2007 11:59:12 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyVFY-0001wG-Kt for sip@ietf.org; Wed, 13 Jun 2007 11:59:12 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5DFx3Ea025395 for ; Wed, 13 Jun 2007 10:59:12 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 10:58:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 17:58:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2007 17:58:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Certificate authentication in SIP Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8A== From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 15:58:32.0066 (UTC) FILETIME=[B0E21620:01C7ADD3] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Sip] Certificate authentication in SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt=20 Describes a set of requirements for: This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). This document is being presented with the intention of providing clear requirements to any potential solutions specifying certificate authentication within SIP networks. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios. (Before we go any further, please forget all about the solutions document - that comes later and we are not dealing with it now) We need to decide whether there is support for a body of work in this area, and therefore whether we should charter some requirements work in the SIP WG. (Because this is security related we have agreed that SIP does the requirements drafting and not SIPPING) So can I hear opinions of the WG on: - whether this represents a problem space that the working group should draft requirements on? - whether the problem space exists but is something slightly different, and if so what is that problem space? - whether there is a more general problem that the security area should be addressing, rather than the SIP group addressing something specific? - based on your answers to the first three questions, whether this draft is essentially in the right direction to be adopted as the WG draft assuming we create the charter item, or whether we need to seek some other input draft? - and finally, whether (assuming we go ahead with this work) there is any work in any other IETF WG that we should take account of? Regards Keith Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 13:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWfq-0006FN-3y; Wed, 13 Jun 2007 13:30:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyWfo-00067F-J4 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 13:30:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWfo-000652-8l for sip@ietf.org; Wed, 13 Jun 2007 13:30:24 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWfn-00064l-2Z for sip@ietf.org; Wed, 13 Jun 2007 13:30:24 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007061317302201100cl0ole>; Wed, 13 Jun 2007 17:30:22 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l5DHUL8t024485 for ; Wed, 13 Jun 2007 13:30:21 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l5DHULO2024481; Wed, 13 Jun 2007 13:30:21 -0400 Date: Wed, 13 Jun 2007 13:30:21 -0400 Message-Id: <200706131730.l5DHULO2024481@dragon.ariadne.com> From: Dale Worley To: sip@ietf.org In-reply-to: <466EDBEF.5040406@mailvision.com> (diegob@mailvision.com) Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <466EDBEF.5040406@mailvision.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There's a lot of talk about INFO and KPML. But people should be aware that most SIP phone systems in the field use RTP (RFC 4733) to transmit DTMF digits. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 13:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWnY-0006tz-F3; Wed, 13 Jun 2007 13:38:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyWnX-0006tu-6R for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 13:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWnW-0006tm-TH for sip@ietf.org; Wed, 13 Jun 2007 13:38:22 -0400 Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWnV-0007sd-Lv for sip@ietf.org; Wed, 13 Jun 2007 13:38:22 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070613173820b1600gd02te>; Wed, 13 Jun 2007 17:38:21 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l5DHcK8t025069 for ; Wed, 13 Jun 2007 13:38:20 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l5DHcKSk025065; Wed, 13 Jun 2007 13:38:20 -0400 Date: Wed, 13 Jun 2007 13:38:20 -0400 Message-Id: <200706131738.l5DHcKSk025065@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> (christer.holmberg@ericsson.com) Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: "Christer Holmberg (JO/LMF)" >Here is another major problem with INFO - there is no header >that states the purpose of INFO. >The event header in subscriptions helps identify an event package. >Therefore an implementation can easily detect if this event >package is supported or not. With INFO it is much harder to >detect the purpose of this INFO message. Currently AFAIK the >content-type in INFO implicitly denotes this. If I send a DTMF digit, the purpose is to send a DTMF digit :) >If you are aiming towards a solution that keeps INFO for more >usages, I would say that we need to resolve this issue first. I am just trying to figure out what the problem really is. There is an ambiguity in what Content-Type means: "what sort of media does this encoded data represent" vs. "what you should do with this data". I don't think there are any cases in current SIP implementations where this is a practical problem. I expect that in most cases where "what you should do with this data" is not completely implied by "what sort of media this represents", the situation will be complex enough that the applications will define extension headers to disambiguate the situation, define extension media types to carry the "intention", or more likely, represent the data as an XML structure which explicitly states the intended action. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 14:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXID-0007Ow-8g; Wed, 13 Jun 2007 14:10:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyXIB-0007OB-Pn for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 14:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXIB-0007ML-55 for sip@ietf.org; Wed, 13 Jun 2007 14:10:03 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyXGf-0007V3-GW for sip@ietf.org; Wed, 13 Jun 2007 14:08:31 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HyXJS-0007Ck-5m; Wed, 13 Jun 2007 13:11:22 -0500 In-Reply-To: <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Wed, 13 Jun 2007 13:08:17 -0500 To: Christer Holmberg (JO/LMF) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 13, 2007, at 4:26 AM, Christer Holmberg (JO/LMF) wrote: > > Hi Dean, > > Thanks for the document. I have read it before, but had forgotten > about it. Probably a healthy response ;-). > > Now, the first issue is how we know that the receiver supports the > Content-Type of the body sent in INFO. There are ways to solve > that, and it is not an INFO specific problem. > beyond "does it understand the content type?", we have the question "does it understand what you want it to do with the content?" > The second issue is regarding the "SIP protocol rules", and I guess > that is one thing which causes confusion. > > For example, if someone wants to send a DTMF tone he sends an INFO > with the DTMF tone. The receiver will determine whether it's needed > for anything (e.g. a robot asking for your PIN code) or not (e.g. > if you're talking to a person and pressed a button by misstake). > What "SIP protocol rules" do you need for that? The application > will determine what/if it does with the received information. "Spray and pray" is fun for kids in street gangs but well-aimed fire is far more efficient and much safer for innocent bystanders. Staying with the use of DTMF/INFO as an example (which, I'd like to add, has been deprecated even if I did originally endorse or maybe even coinvent it) . . . Before you send a DTMF/INFO, you really need to know that the recipient understands DTMF/INFO in general and the specific encoding of DTMF in INFO that you're using (there have been multiple encodings proposed). Otherwise you wouldn't even bother sending it unless you're a hopeless optimist, trying to impress your homies with the size of your packet-slinger, or just plain stoopid. And beyond just understanding your encoding of DTMF/INFO, you need to know that the recipient you are sending it to is likely to do something useful with that INFO, and that this "something useful" is what you intend it to do when you send it. Now, for DTMF/INFO the "something useful" is pretty straightforward -- take the tone sequences and either use them as input to a local application or mix them back into the media stream. Other possible uses for INFO (and there have been many proposed) are not generally so clear. For example, if I send you an INFO containing a JPEG file, what are you supposed to do with it? Project the image onto the wall? Use it is a keyboard map? Use it as a voiceprint graph for spectral comparison with my media stream as a means of performing a MITM detection? (hey, I think I just invented something . . .) Or something entirely different? What is wrong with INFO as currently specified is that we have no way of answering these questions. Content-disposition and content-type just aren't rich enough for the range of possibilities. So we either have to rigorously NOT use INFO for anything new (and it is currently defined only for telephony tunneling), or extend it to be able to differentiate usages. My personal feeling is that the wild INFO cat has leapt out of the bag and run off to have kittens, so we're better off giving those kittens names and vaccinations than we are trying to convince people not to pet the cat. -- 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 sip-bounces@ietf.org Wed Jun 13 15:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYTK-0001PG-1e; Wed, 13 Jun 2007 15:25:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyYTI-0001P9-3V for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 15:25:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYTH-0001P1-QG for sip@ietf.org; Wed, 13 Jun 2007 15:25:35 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYSz-0006NE-Ks for sip@ietf.org; Wed, 13 Jun 2007 15:25:35 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5DJOgOe025590; Wed, 13 Jun 2007 14:25:16 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:24:54 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 21:24:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Wed, 13 Jun 2007 21:24:50 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> In-Reply-To: <466F5E26.2000709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Thread-Index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeA References: <466F5E26.2000709@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 19:24:51.0589 (UTC) FILETIME=[83A76350:01C7ADF0] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) As well as agreeing to charter the item, we actually agreed at IETF#67 that this draft was a suitable candidate to fulfil that charter item.=20 Therefore unless issues are raised with this, I would request the editor (as Jonathan is editor) to submit the next version of this document as draft-ietf-sip-ua-loose-route-00. Regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Wednesday, June 13, 2007 4:02 AM > To: IETF SIP List > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility >=20 > I've recently revised my draft on UA loose routing. You can=20 > pick it up here: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > se-route-01.txt >=20 > This draft is meant to fulfill one of our charter items: > Feb 2008 Delivering request-URI and parameters=20 > to UAS via proxy to=20 > IESG (PS) >=20 > As folks may recall, the GRUU spec used to have these things=20 > called grids, which allowed a UA to add its own parameters to=20 > the GRUU before handing it out. Several GRUU revisions back,=20 > this function got yanked because it was recognized that the=20 > problem was more general than GRUU, and would be useful for=20 > AOR as well. >=20 > Two IETFs back I presented this draft briefly during a SIP session.=20 > There was a lot of interest and people liked it=20 > architecturally, however there were two open issues that=20 > needed to get resolved. This mail is meant to start=20 > discussion on one of them - backwards compatibility. >=20 > THe mechanism basically changes the way proxies handle=20 > requests. Instead of rewriting the request URI for=20 > out-of-dialog requests, they'll push a route header and leave=20 > the r-uri alone. This allows the original R-URI and any=20 > parameters it contains to get delivered to the UAS. >=20 > So, the main issue is, what kinds of backwards compatibility=20 > problems will this cause. The draft provides a basic=20 > mechanism whereby a UA includes an option tag in the=20 > REGISTER, and the registrar indicates that it is using this=20 > mechanism or not. So we can negotiate this between a UA and=20 > registrar easily. Now, the problem is with intermediate=20 > proxies. If there is an edge proxy between the UA and its=20 > registrar, it will now see requests targeted to the UA, which=20 > contain a Route header beyond itself, even though it thinks=20 > its the edge proxy and the last point of contact before the=20 > UA. Technically, if this edge proxy is compliant to rfc3261=20 > it would work. However, the question is whether proxies in=20 > the wild would properly work in this case. >=20 > If folks can comment based on their own products, or their=20 > experiences, on whether they think this would work, or=20 > concerns they have, that would be great. THere are solutions=20 > that would allow us to disable the mechanism when=20 > intermediate proxies don't support it, but they are more=20 > complex and I'd rather avoid it. >=20 > THanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 15:47:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYo9-0003sG-Hk; Wed, 13 Jun 2007 15:47:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyYo7-0003ni-Kq for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 15:47:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYo7-0003mf-Af for sip@ietf.org; Wed, 13 Jun 2007 15:47:07 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYo6-0002PN-J8 for sip@ietf.org; Wed, 13 Jun 2007 15:47:07 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D8CCF20570; Wed, 13 Jun 2007 21:47:05 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-82-467049b948f1 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B8F5C203CE; Wed, 13 Jun 2007 21:47:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 21:47:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Wed, 13 Jun 2007 21:47:02 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: Acet5d7Y1jtqHJBSQP+/lLO9FxyAGAACd8FQ References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Dean Willis" X-OriginalArrivalTime: 13 Jun 2007 19:47:05.0345 (UTC) FILETIME=[9EA26710:01C7ADF3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>Now, the first issue is how we know that the receiver supports the=20 >>Content-Type of the body sent in INFO. There are ways to=20 >>solve that, and it is not an INFO specific problem. > >=20 >beyond "does it understand the content type?", we have the question "does it understand what you want it to do with the=20 >content?" Yes. >>The second issue is regarding the "SIP protocol rules", and I guess=20 >>that is one thing which causes confusion. >> >>For example, if someone wants to send a DTMF tone he sends an INFO=20 >>with the DTMF tone. The receiver will determine whether it's needed=20 >>for anything (e.g. a robot asking for your PIN code) or not (e.g. >>if you're talking to a person and pressed a button by misstake). =20 >>What "SIP protocol rules" do you need for that? The=20 >>application will determine what/if it does with the received information. >=20 >=20 >"Spray and pray" is fun for kids in street gangs but=20 >well-aimed fire is far more efficient and much safer for =20 >innocent bystanders. I don't think an application will trigger INFOs in a spray and pray matter. You will only send media server control messages if you are communicating with a media server control application that understands them. >Staying with the use of DTMF/INFO as an example (which, I'd=20 >like to add, has been deprecated even if I did originally=20 >endorse or maybe even coinvent it) . . . It hasn't been deprecated outside out on the field. >Before you send a DTMF/INFO, you really need to know that the=20 >recipient understands DTMF/INFO in general and the specific=20 >encoding of DTMF in INFO that you're using (there have been=20 >multiple encodings proposed). Yes, and you know that if you receive an indication from the other party that he supports application/my-dtmf (or whatever value is used). And, if we would have standardized one encoding, maybe there wouldn't be multiple ones out there... >Otherwise you wouldn't even bother sending it unless you're a hopeless optimist, trying=20 >to impress your homies with the size of your packet-slinger, or just plain stoopid. I totally agree. >And beyond just understanding your encoding of DTMF/INFO, you=20 >need to know that the recipient you are sending it to is=20 >likely to do something useful with that INFO, and that this=20 >"something useful" is what you intend it to do when you send it. Yes, but you wouldn't send it unless you have a reason to think the receiver is going to do something with it, e.g. if you have been asked to give your PIN code.=20 I don't understand why people think that applications would start sending all kind of INFOs "just for fun", without any logic behind. I have never seen that happen in real world deployments. I wouldn't start sending UPDATEs and/or re-INVITEs just for fun either, eventhough there is nothing preventing me from doing it. Just because you CAN doesn't mean you WILL :) =20 >Now, for DTMF/INFO the "something useful" is pretty straightforward >-- take the tone sequences and either use them as input to a=20 >local application or mix them back into the media stream. >=20 >Other possible uses for INFO (and there have been many=20 >proposed) are not generally so clear. For example, if I send=20 >you an INFO containing a JPEG file, what are you supposed to=20 >do with it? Project the image onto the wall? Use it is a=20 >keyboard map? Use it as a voiceprint graph for spectral=20 >comparison with my media stream as a means of performing a=20 >MITM detection? (hey, I think I just invented something . .=20 >.) Or something entirely different? That depends on the application. For example, the application may tell you that a JPEG file has arrived, and ask what you want to do with it. You may choose to project it, use it as a keyboard map, or whatever. But, again, I don't think anyone is going to send you the JPEG file "just like that", without any reason. >What is wrong with INFO as currently specified is that we=20 >have no way of answering these questions. Content-disposition=20 >and content-type just aren't rich enough for the range of=20 >possibilities. I don't think we need to answer those questions, because they are application specific. What we need to answer is the question how to indicate what Content-Types the receiver supports, and is willing to receive for a given session.=20 What we also should care about is to make sure that the Content-Types are standardized, so that we don't have multiple, uninteroperable, mechanisms doing the same thing out there. >So we either have to rigorously NOT use INFO for anything new=20 >(and it is currently defined only for telephony tunneling),=20 >or extend it to be able to differentiate usages. My personal=20 >feeling is that the wild INFO cat has leapt out of the bag=20 >and run off to have kittens, so we're better off giving those=20 >kittens names and vaccinations than we are trying to convince=20 >people not to pet the cat. I agree with you. I think that INFO is an easy and useful tool, and the market seems to think the same thing. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 15:52:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYt0-0007ct-1P; Wed, 13 Jun 2007 15:52:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyYsy-0007ci-T9 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 15:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYsy-0007ca-Jb for sip@ietf.org; Wed, 13 Jun 2007 15:52:08 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYsu-0003V5-7K for sip@ietf.org; Wed, 13 Jun 2007 15:52:08 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B7E63203D1; Wed, 13 Jun 2007 21:52:03 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-ad-46704ae3acd3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92EEF20048; Wed, 13 Jun 2007 21:52:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 21:52:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Wed, 13 Jun 2007 21:52:02 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing thread-index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SA= References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "DRAGE, Keith (Keith)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 19:52:03.0033 (UTC) FILETIME=[5011FC90:01C7ADF4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, We can call it loose route if we want, but I think the initial focus = should be the problem we are going to solve (I don't think we agreed on = a specific solution at #67), and we should look into alternative = solutions (the draft does that in some extent, but other possible = alternatives have also been mentioned). Or, do you prefer to have separate drafts describing alternative = solutions for the problem? Regards, Christer =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 13. kes=E4kuuta 2007 22:25 > To: Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing >=20 > (As WG chair) >=20 > As well as agreeing to charter the item, we actually agreed=20 > at IETF#67 that this draft was a suitable candidate to fulfil=20 > that charter item.=20 >=20 > Therefore unless issues are raised with this, I would request=20 > the editor (as Jonathan is editor) to submit the next version=20 > of this document as draft-ietf-sip-ua-loose-route-00. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Wednesday, June 13, 2007 4:02 AM > > To: IETF SIP List > > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility > >=20 > > I've recently revised my draft on UA loose routing. You can=20 > pick it up=20 > > here: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > se-route-01.txt > >=20 > > This draft is meant to fulfill one of our charter items: > > Feb 2008 Delivering request-URI and parameters=20 > > to UAS via proxy to > > IESG (PS) > >=20 > > As folks may recall, the GRUU spec used to have these things called=20 > > grids, which allowed a UA to add its own parameters to the=20 > GRUU before=20 > > handing it out. Several GRUU revisions back, this function=20 > got yanked=20 > > because it was recognized that the problem was more general=20 > than GRUU,=20 > > and would be useful for AOR as well. > >=20 > > Two IETFs back I presented this draft briefly during a SIP session.=20 > > There was a lot of interest and people liked it architecturally,=20 > > however there were two open issues that needed to get=20 > resolved. This=20 > > mail is meant to start discussion on one of them - backwards=20 > > compatibility. > >=20 > > THe mechanism basically changes the way proxies handle requests.=20 > > Instead of rewriting the request URI for out-of-dialog requests,=20 > > they'll push a route header and leave the r-uri alone. This=20 > allows the=20 > > original R-URI and any parameters it contains to get=20 > delivered to the=20 > > UAS. > >=20 > > So, the main issue is, what kinds of backwards=20 > compatibility problems=20 > > will this cause. The draft provides a basic mechanism whereby a UA=20 > > includes an option tag in the REGISTER, and the registrar indicates=20 > > that it is using this mechanism or not. So we can negotiate this=20 > > between a UA and registrar easily. Now, the problem is with=20 > > intermediate proxies. If there is an edge proxy between the=20 > UA and its=20 > > registrar, it will now see requests targeted to the UA,=20 > which contain=20 > > a Route header beyond itself, even though it thinks its the=20 > edge proxy=20 > > and the last point of contact before the UA. Technically,=20 > if this edge=20 > > proxy is compliant to rfc3261 it would work. However, the=20 > question is=20 > > whether proxies in the wild would properly work in this case. > >=20 > > If folks can comment based on their own products, or their=20 > > experiences, on whether they think this would work, or=20 > concerns they=20 > > have, that would be great. THere are solutions that would=20 > allow us to=20 > > disable the mechanism when intermediate proxies don't=20 > support it, but=20 > > they are more complex and I'd rather avoid it. > >=20 > > THanks, > > Jonathan R. > > --=20 > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ=20 > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 15:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYyH-0008G6-3B; Wed, 13 Jun 2007 15:57:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyYyF-0008Fz-NM for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 15:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYyF-0008Fr-Cs for sip@ietf.org; Wed, 13 Jun 2007 15:57:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYyE-0004wl-2N for sip@ietf.org; Wed, 13 Jun 2007 15:57:35 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5DJvTmr019871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2007 12:57:30 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5DJvRxq001600; Wed, 13 Jun 2007 12:57:29 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> References: <466F5E26.2000709@cisco.com> <7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> Date: Wed, 13 Jun 2007 12:57:26 -0700 To: "Christer Holmberg (JO/LMF)" , "Jonathan Rosenberg" , "IETF SIP List" From: Ted Hardie Subject: Re: [Sip] UA Loose Routing: Emergency example Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org At 2:53 PM +0200 6/13/07, Christer Holmberg (JO/LMF) wrote: >Hi, > >This is not very relevant to the loose route solution as such, but just >a small comment on the emergency service use-case. > >I am not sure whether the emergency service centers will always >register, and if they don't loose route of course does not solve the >problem. > >Regards, > >Christer Hi Christer, Can you expand on the issue here? I'm afraid I didn't understand it from this message. thanks, Ted _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 16:02:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ3O-0006H7-9A; Wed, 13 Jun 2007 16:02:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyZ3N-0006H1-E3 for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 16:02:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyZ3N-0006Gt-4P for sip@ietf.org; Wed, 13 Jun 2007 16:02:53 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyZ3L-00067p-QX for sip@ietf.org; Wed, 13 Jun 2007 16:02:53 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 39C16204F1; Wed, 13 Jun 2007 22:02:51 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-47-46704d6b8f9c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 29729204BE; Wed, 13 Jun 2007 22:02:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 22:02:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing: Emergency example Date: Wed, 13 Jun 2007 22:02:50 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705397563@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing: Emergency example thread-index: Acet9RUiumgJTZuuTMeNxUH+z/4DYAAADeeA References: <466F5E26.2000709@cisco.com> <7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Ted Hardie" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 13 Jun 2007 20:02:50.0591 (UTC) FILETIME=[D20B7EF0:01C7ADF5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>This is not very relevant to the loose route solution as such, but just=20 >>a small comment on the emergency service use-case. >> >>I am not sure whether the emergency service centers will always=20 >>register, and if they don't loose route of course does not solve the=20 >>problem. >> >>Regards, >> >>Christer >=20 >Hi Christer, > =09 >Can you expand on the issue here? I'm afraid I didn't understand it from this message. As said in the draft, the loose route mechanism can only be used if the UA has registered and indicated support of the loose route mechanism. So, entities that do not register will not be able to use the mechanism. And, to my understanding the ESCs will not always register, which mean it's not possible to use the loose route mechanism to forward the initial request to them. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 17:45:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyaeh-00018A-GW; Wed, 13 Jun 2007 17:45:31 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyaeg-000185-KB for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 17:45:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyaeg-00017x-AY for sip@ietf.org; Wed, 13 Jun 2007 17:45:30 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyaef-0000hY-1v for sip@ietf.org; Wed, 13 Jun 2007 17:45:30 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l5DLiwTV022553; Wed, 13 Jun 2007 15:44:58 -0600 Message-ID: <46706547.1000405@ntt-at.com> Date: Wed, 13 Jun 2007 14:44:39 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] draft-ietf-sip-saml-02 References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I just glanced at the diff from the previous version that I read (ver-01). > > - completeness - is there something missing? > Some of the major issues addressed on the list and on the SIP-SAML list (separate list that was active a while back to discuss SAML usage in SIP) has not been resolved. Some of which may require an extension or change to the dependent draft (e.g. SIP-Identity). So I would have to say that it's still far from complete. > - applicability - does it identify and solve a problem? > Yes. > - readability - I didn't understand what it was trying to tell me? > The text in the draft is fairly comprehensive and easy to understand. > - correctness of technical solution - the solution is flawed? > I believe the solution and approach seems to be sound, but will need to see how the remaining issues are going to be addressed. Regards Shida _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 17:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyahh-000459-7d; Wed, 13 Jun 2007 17:48:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyahf-000454-IS for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 17:48:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyahf-00044w-8l for sip@ietf.org; Wed, 13 Jun 2007 17:48:35 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyahe-0001FV-Mj for sip@ietf.org; Wed, 13 Jun 2007 17:48:35 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 13 Jun 2007 14:48:33 -0700 X-IronPort-AV: i="4.16,418,1175497200"; d="scan'208"; a="18542900:sNHT47965650" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 22:48:32 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Wed, 13 Jun 2007 22:48:29 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A537A6@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: Acet5d7Y1jtqHJBSQP+/lLO9FxyAGAACd8FQAAPTTiA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" , "Dean Willis" X-OriginalArrivalTime: 13 Jun 2007 21:48:32.0203 (UTC) FILETIME=[95F0B1B0:01C7AE04] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Comments inline > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 13, 2007 10:47 PM > To: Dean Willis > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi, >=20 > >>Now, the first issue is how we know that the receiver supports the > >>Content-Type of the body sent in INFO. There are ways to > >>solve that, and it is not an INFO specific problem. > > > > > >beyond "does it understand the content type?", we have the question > "does it understand what you want it to do with the > >content?" >=20 > Yes. >=20 > >>The second issue is regarding the "SIP protocol rules", and I guess > >>that is one thing which causes confusion. > >> > >>For example, if someone wants to send a DTMF tone he sends an INFO > >>with the DTMF tone. The receiver will determine whether it's needed > >>for anything (e.g. a robot asking for your PIN code) or not (e.g. > >>if you're talking to a person and pressed a button by misstake). > >>What "SIP protocol rules" do you need for that? The > >>application will determine what/if it does with the received > information. > > > > > >"Spray and pray" is fun for kids in street gangs but > >well-aimed fire is far more efficient and much safer for > >innocent bystanders. >=20 > I don't think an application will trigger INFOs in a spray and pray > matter. You will only send media server control messages if you are > communicating with a media server control application that understands > them. >=20 Don't we need something that indicates to each UA what types of INFOs the other UA should get? I still don't agree there is a 1:1 relationship between content type and info purpose. > >Staying with the use of DTMF/INFO as an example (which, I'd > >like to add, has been deprecated even if I did originally > >endorse or maybe even coinvent it) . . . >=20 > It hasn't been deprecated outside out on the field. That depends on what "it" means, there are several old drafts for this single functionality, for example one proposed to send MGCP in the body. Another proposed a specific body. There are probably more. So is our approach to document and standardize any proprietary implementation for this? Even when we have alternatives? >=20 > >Before you send a DTMF/INFO, you really need to know that the > >recipient understands DTMF/INFO in general and the specific > >encoding of DTMF in INFO that you're using (there have been > >multiple encodings proposed). >=20 > Yes, and you know that if you receive an indication from the other party > that he supports application/my-dtmf (or whatever value is used). >=20 > And, if we would have standardized one encoding, maybe there wouldn't be > multiple ones out there... >=20 > >Otherwise you wouldn't even bother sending it unless you're a hopeless > optimist, trying > >to impress your homies with the size of your packet-slinger, or just > plain stoopid. >=20 > I totally agree. >=20 > >And beyond just understanding your encoding of DTMF/INFO, you > >need to know that the recipient you are sending it to is > >likely to do something useful with that INFO, and that this > >"something useful" is what you intend it to do when you send it. >=20 > Yes, but you wouldn't send it unless you have a reason to think the > receiver is going to do something with it, e.g. if you have been asked > to give your PIN code. >=20 > I don't understand why people think that applications would start > sending all kind of INFOs "just for fun", without any logic behind. I > have never seen that happen in real world deployments. I wouldn't start > sending UPDATEs and/or re-INVITEs just for fun either, eventhough there > is nothing preventing me from doing it. >=20 > Just because you CAN doesn't mean you WILL :) Is the assumption that INFO is triggered by user and not by something in the flow? Let's say I invent INFO that sends information on voice quality in a call every X seconds. How does one indicate this will/should be sent? >=20 > >Now, for DTMF/INFO the "something useful" is pretty straightforward > >-- take the tone sequences and either use them as input to a > >local application or mix them back into the media stream. > > > >Other possible uses for INFO (and there have been many > >proposed) are not generally so clear. For example, if I send > >you an INFO containing a JPEG file, what are you supposed to > >do with it? Project the image onto the wall? Use it is a > >keyboard map? Use it as a voiceprint graph for spectral > >comparison with my media stream as a means of performing a > >MITM detection? (hey, I think I just invented something . . > >.) Or something entirely different? >=20 > That depends on the application. For example, the application may tell > you that a JPEG file has arrived, and ask what you want to do with it. > You may choose to project it, use it as a keyboard map, or whatever. >=20 > But, again, I don't think anyone is going to send you the JPEG file > "just like that", without any reason. What if each is sent for a different reason and not just one picture is sent? How do you tell the application "the reason"? >=20 > >What is wrong with INFO as currently specified is that we > >have no way of answering these questions. Content-disposition > >and content-type just aren't rich enough for the range of > >possibilities. >=20 > I don't think we need to answer those questions, because they are > application specific. >=20 > What we need to answer is the question how to indicate what > Content-Types the receiver supports, and is willing to receive for a > given session. >=20 > What we also should care about is to make sure that the Content-Types > are standardized, so that we don't have multiple, uninteroperable, > mechanisms doing the same thing out there. >=20 I tend to feel it's not enough. > >So we either have to rigorously NOT use INFO for anything new > >(and it is currently defined only for telephony tunneling), > >or extend it to be able to differentiate usages. My personal > >feeling is that the wild INFO cat has leapt out of the bag > >and run off to have kittens, so we're better off giving those > >kittens names and vaccinations than we are trying to convince > >people not to pet the cat. >=20 > I agree with you. >=20 This is not your everyday kitten. This big cat bites and scratches. Or maybe I've taken the metaphor too far... Really - other than SIP-T, I don't understand so far what necessary usages INFO has that do not have other viable/better alternatives. Just because some company X did something and perhaps even company Y mimicked it, who said it's a good idea. For any new usage I think of for INFO I find a better solution in SUBSCRIBE-NOTIFY... Just like INFO should not be sent just for the heck of it, INFO usages should not be invented just because it's possible. > I think that INFO is an easy and useful tool, and the market seems to > think the same thing. I agree it's easy. Can it ease some implementation? >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 19:14:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyc2E-0002mC-DH; Wed, 13 Jun 2007 19:13:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyc2D-0002m5-3c for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 19:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyc2C-0002lv-QN for sip@ietf.org; Wed, 13 Jun 2007 19:13:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyc2B-0001v2-Ff for sip@ietf.org; Wed, 13 Jun 2007 19:13:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2007 19:13:51 -0400 X-IronPort-AV: i="4.16,418,1175486400"; d="scan'208"; a="62703713:sNHT49922862" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5DNDpD6024095; Wed, 13 Jun 2007 19:13:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5DND25v007609; Wed, 13 Jun 2007 23:13:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:13:34 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:13:34 -0400 Message-ID: <46707A1C.1060909@cisco.com> Date: Wed, 13 Jun 2007 19:13:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <200706131738.l5DHcKSk025065@dragon.ariadne.com> In-Reply-To: <200706131738.l5DHcKSk025065@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2007 23:13:34.0243 (UTC) FILETIME=[76FE3730:01C7AE10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3204; t=1181776431; x=1182640431; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=KyokPvWHkE4Lr1FmQXYvbQl8PEf5wXpigEbuT1Nym3o=; b=PXWM6bp01Aj98ZSw7/MkAzHcztqeXEuNjipIkwETxUYb1NLpaPDBXCgEUbEJ8/qESOX4ddT4 g0dkqgo+kFNhuFUM5QlvRJ8xWoh15HVfRtaORM45G2ZR8Z5WcXyroyBG; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org See http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt Content-Disposition is another part of the puzzle, as is use of headers that refer to body parts using cid: URIs. And the method is another criterion. As a more difficult example, what do you suppose you should do if you receive an INFO message in a dialog, with a content-type of text/plain and a content-disposition of "render"? How would that handling differ from what you would do if it was a MESSAGE but otherwise the same? You can pick out special cases and say "duh - what else could you do with DTMF digits"? But when you sit down to program a UA you need to come up with well defined algorithms to decide this stuff. As UAs get more and more sophisticated in the range of things they can do it will get more and more important to have semantics be well defined. My problem with INFO is precisely because it has no semantics of how it should be processed, or how body parts that it carries should be processed differently than if the same parts were in some other message. If there is some header and/or body part that should be processed the same, regardless of what message it is delivered in, then I have no problem with using INFO to convey it. But I don't think we have any of those. Paul Dale.Worley@comcast.net wrote: > From: "Christer Holmberg (JO/LMF)" > > >Here is another major problem with INFO - there is no header > >that states the purpose of INFO. > >The event header in subscriptions helps identify an event package. > >Therefore an implementation can easily detect if this event > >package is supported or not. With INFO it is much harder to > >detect the purpose of this INFO message. Currently AFAIK the > >content-type in INFO implicitly denotes this. > > If I send a DTMF digit, the purpose is to send a DTMF digit :) > > >If you are aiming towards a solution that keeps INFO for more > >usages, I would say that we need to resolve this issue first. > > I am just trying to figure out what the problem really is. > > There is an ambiguity in what Content-Type means: "what sort of media > does this encoded data represent" vs. "what you should do with this > data". I don't think there are any cases in current SIP > implementations where this is a practical problem. I expect that in > most cases where "what you should do with this data" is not completely > implied by "what sort of media this represents", the situation will be > complex enough that the applications will define extension headers to > disambiguate the situation, define extension media types to carry the > "intention", or more likely, represent the data as an XML structure > which explicitly states the intended action. > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 13 19:37:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycOg-0004KM-5Y; Wed, 13 Jun 2007 19:37:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HycOf-0004KG-GF for sip-confirm+ok@megatron.ietf.org; Wed, 13 Jun 2007 19:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycOf-0004K8-6l for sip@ietf.org; Wed, 13 Jun 2007 19:37:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HycOe-0006Hy-TL for sip@ietf.org; Wed, 13 Jun 2007 19:37:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2007 19:37:05 -0400 X-IronPort-AV: i="4.16,418,1175486400"; d="scan'208"; a="123569749:sNHT55742368" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5DNb4KF013175; Wed, 13 Jun 2007 19:37:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5DNar5f012063; Wed, 13 Jun 2007 23:36:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:36:37 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 19:36:37 -0400 Message-ID: <46707F86.6060901@cisco.com> Date: Wed, 13 Jun 2007 19:36:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2007 23:36:37.0717 (UTC) FILETIME=[AF9B9850:01C7AE13] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3402; t=1181777824; x=1182641824; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=p/q+6BPcSBsvU9IY/8FIYyKqtsv/i8rZvdbQPWf/ES4=; b=OpIAUb9zKeyNZ3EEEyUxzTVtEpZ91ItlO+CjaP9yjo8CZ4nHE2Na1RBmmv+cWrKO3IlgPM+0 ZufDLaimPI6ioqOHXngrOgA4DHGyWDE2Z0idtoRebvFmzGbxk7oHOAwy; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > I don't think an application will trigger INFOs in a spray and pray > matter. You will only send media server control messages if you are > communicating with a media server control application that understands > them. How does my phone know it is communicating with a media server that understands INFO for conveying DTMF? The thing I call may indicate support of INFO because it supports qsig tunneling. >> Before you send a DTMF/INFO, you really need to know that the >> recipient understands DTMF/INFO in general and the specific >> encoding of DTMF in INFO that you're using (there have been >> multiple encodings proposed). > > Yes, and you know that if you receive an indication from the other party > that he supports application/my-dtmf (or whatever value is used). > > And, if we would have standardized one encoding, maybe there wouldn't be > multiple ones out there... We currently have no way to say "I support mime-type foo for use with disposition bar and method baz", but in reality that is going to be the situation. I support sdp for disposition "session" in the methods that convey o/a. But I don't support sdp in MESSAGE or INFO. I support text/plain with content-type "render" in MESSAGE, but not for other dispositions and other message types. Getting an indication of support for application/my-dtmf is useful *if* you know that the UA sending it to you always uses it the same ways you do. You can only know that if you control it, or if all the uses of that type are standardized. >> And beyond just understanding your encoding of DTMF/INFO, you >> need to know that the recipient you are sending it to is >> likely to do something useful with that INFO, and that this >> "something useful" is what you intend it to do when you send it. > > Yes, but you wouldn't send it unless you have a reason to think the > receiver is going to do something with it, e.g. if you have been asked > to give your PIN code. > > I don't understand why people think that applications would start > sending all kind of INFOs "just for fun", without any logic behind. I > have never seen that happen in real world deployments. I wouldn't start > sending UPDATEs and/or re-INVITEs just for fun either, eventhough there > is nothing preventing me from doing it. Lets go back to my phone. *It* doesn't know that I have been asked to give my PIN code, even though I do. All my phone knows is that I have pressed one of the buttons on the keypad. It may reasonably infer that I want *something* to be done with them, and probably that I want them sent to the other end in some way. It has no idea *how* (or *if*) the other end is prepared to receive them. For instance, it may have indicated support for a mime type that my phone knows how to use to encode DTMF. But its possible it was really trying to say that it would support that type in a NOTIFY (sent or received). I will agree that if you have N different ways that you are able to send DTMF, and if the other party has indicated support for *something* that is consistent with one of them and not with any of the others, then you might reasonably decide to try that one. But it is still a somewhat iffy proposition. We would be much better served defining something more deterministic. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 03:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk9t-0000cm-Mv; Thu, 14 Jun 2007 03:54:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyk9s-0000cg-8X for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 03:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk9o-0000cN-O9 for sip@ietf.org; Thu, 14 Jun 2007 03:54:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyk9l-0001sq-Mp for sip@ietf.org; Thu, 14 Jun 2007 03:54:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B1D102130F; Thu, 14 Jun 2007 09:54:12 +0200 (CEST) X-AuditID: c1b4fb3e-b0e79bb0000007e1-13-4670f424b137 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9D146212AD; Thu, 14 Jun 2007 09:54:12 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 09:54:12 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 09:54:12 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3BE912342; Thu, 14 Jun 2007 10:54:12 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 01B5D4DB5F; Thu, 14 Jun 2007 10:54:12 +0300 (EEST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A0CD84DAE1; Thu, 14 Jun 2007 10:54:11 +0300 (EEST) From: Salvatore Loreto To: Jonathan Rosenberg In-Reply-To: <466F5E26.2000709@cisco.com> References: <466F5E26.2000709@cisco.com> Content-Type: text/plain Date: Thu, 14 Jun 2007 10:54:11 +0300 Message-Id: <1181807651.4027.33.camel@n84.nomadiclab.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 14 Jun 2007 07:54:12.0367 (UTC) FILETIME=[325DA9F0:01C7AE59] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List Subject: [Sip] UA Loose Routing: redirect X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jonathan, about the third redirection meaning: 3. The server is asking the client to route through an additional proxy prior to visiting it, so that the recursed request generated by the client pushes an additional Route onto the Route set. I was wondering if it should be possible insert more than only one contact into the existing route set. I'd like to know your opinion, because in my understanding it should not possible due to the "alternative" meaning of different locations into the the Contact header field; in fact the RFC3261 states: "When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An "expires" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data." About the persistence of the redirection for a mid-dialog request, I am not sure it should persist just for the duration of the transaction, instead the persistence should be managed by the "expires" parameter. regards Sal _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylUd-0001Pv-IT; Thu, 14 Jun 2007 05:19:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HylUc-0001Pm-7V for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylUb-0001Pb-RY for sip@ietf.org; Thu, 14 Jun 2007 05:19:49 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylUa-0006NH-V8 for sip@ietf.org; Thu, 14 Jun 2007 05:19:49 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5A45E21328; Thu, 14 Jun 2007 11:19:48 +0200 (CEST) X-AuditID: c1b4fb3e-b167abb0000007e1-b5-46710834b81d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 39B5120555; Thu, 14 Jun 2007 11:19:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:19:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 14 Jun 2007 11:19:47 +0200 Message-ID: <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> In-Reply-To: <46707F86.6060901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSw References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 14 Jun 2007 09:19:47.0993 (UTC) FILETIME=[27700090:01C7AE65] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I don't think an application will trigger INFOs in a spray and pray=20 >>matter. You will only send media server control messages if you are=20 >>communicating with a media server control application that=20 >>understands them. >=20 >How does my phone know it is communicating with a media=20 >server that understands INFO for conveying DTMF? The thing I=20 >call may indicate support of INFO because it supports qsig tunneling. It should also indicate support (using the Accept header) of the content-type which is used to transport the media control messages. =20 >>>Before you send a DTMF/INFO, you really need to know that the recipient understands DTMF/INFO in general and the=20 >>>specific encoding of DTMF in INFO that you're using (there have been=20 >>>multiple encodings proposed). >>=20 >>Yes, and you know that if you receive an indication from the other party that he supports application/my-dtmf (or whatever=20 >value is used). >>=20 >>And, if we would have standardized one encoding, maybe there wouldn't=20 >>be multiple ones out there... >=20 >We currently have no way to say "I support mime-type foo for=20 >use with disposition bar and method baz", but in reality that=20 >is going to be the situation. I support sdp for disposition=20 >"session" in the methods that convey o/a. But I don't support=20 >sdp in MESSAGE or INFO. I support text/plain with content-type "render" in MESSAGE, but not for other=20 >dispositions and other message types. You don't have any way to say "I support mime-type SDP for use with disposition bar and method baz" either - that we specify elsewhere. And, if we define a DTMF mime-type, we should of course also say in which SIP message it can be used etc. But, again, we should not specify the applications that are going to use it. Also, since INFO is not supposed to affect the SIP session, we can also put restrictions on which disposition values are to be used etc. So, of course there is some work to do, but that's not a reason to reject something. If everything was done and ready, there would be no need for the SIP WG :) >Getting an indication of support for application/my-dtmf is=20 >useful *if* you know that the UA sending it to you always=20 >uses it the same ways you do. You can only know that if you=20 >control it, or if all the uses of that type are standardized. It's up to the applications to make sure that the DTMFs are sent and intepreted. If the receiving application has not asked for DTMFs, and the sender still sends them, the receiver should simply discard them. It's part of the application logic - not the SIP protocol. The SIP protocol defines information elements to indicate what content types you support, what actions to take if the content type is not supported etc. But, again: we don't specify what the applicatons are going to do with information. It's similar to when you use RFC2833 for sending DTMFs. The only thing you do, as part of the offer/answer procedure, is agreeing that both endpoints support RFC2833 - but you do not specify what the endpoints are going to do with the tones, when they will be sent etc. >>>And beyond just understanding your encoding of DTMF/INFO, you need to >>>know that the recipient you are sending it to is likely to do=20 >>>something useful with that INFO, and that this "something useful" is=20 >>>what you intend it to do when you send it. >> >>Yes, but you wouldn't send it unless you have a reason to think the=20 >>receiver is going to do something with it, e.g. if you have=20 >>been asked to give your PIN code. >>=20 >>I don't understand why people think that applications would start=20 >>sending all kind of INFOs "just for fun", without any logic=20 >>behind. I have never seen that happen in real world deployments. I wouldn't=20 >>start sending UPDATEs and/or re-INVITEs just for fun either,=20 >>eventhough there is nothing preventing me from doing it. >=20 >Lets go back to my phone. *It* doesn't know that I have been=20 >asked to give my PIN code, even though I do. All my phone=20 >knows is that I have pressed one of the buttons on the=20 >keypad. It may reasonably infer that I want *something* to be=20 >done with them, and probably that I want them sent to the=20 >other end in some way. It has no idea *how* (or *if*) the=20 >other end is prepared to receive them. I think what you are talking about is how you will design your SIP phone. For example, on my table phone, if I during a call want to send DTMF tones I have to first press one button to "active" DTMF, and then any button I sent is sent as DTMF. If I am asked to give my PIN code, but do not active DTMF, nothing will happen when I press the buttons. On my GSM phone, however, I don't need to active DTMF. If I am asked to give my PIN code, I simply press buttons and they are sent as DTMF tones. >For instance, it may have indicated support for a mime type=20 >that my phone knows how to use to encode DTMF. But its=20 >possible it was really trying to say that it would support=20 >that type in a NOTIFY (sent or received). IF there are missing parts in the negotiation mechanism, we need to fix that. Something like: Accept: application/my-dtmf;method=3DINFO OR, in the draft defining the content type, we specify that content type X can only be sent using this and that method. I belive we do the same thing for SDP. But, so far we haven't been interested in looking into these issues. We just say that using INFO is against the spirit of SIP, it causes all kind of problems etc etc. My intention is not to "promote" the usage of INFO. My issue is that the market has found and deployed an easy and effective way of doing things using INFO, without breaking the protocol, and what worries me is that instead of trying to help the market (e.g. by standardizing the content types, providing negotiation mechanism to achieve interoperability), and in that way indirectly help them to come up with new SIP applications, we simply tell them that what they are doing (and have been doing for years) is wrong, that they are breaking SIP, etc etc etc. And, if we really wanted to restrict the usage of INFO, it should have been done a long time ago - not years after the INFO RFC is published and people have deployed usages of it. Anyway, I guess we can go on with this discussion forever. Maybe we should find some time in Chicago and sit down and discuss this? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylhp-000590-Ed; Thu, 14 Jun 2007 05:33:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hylhn-00056Y-9P for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:33:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylhm-000563-M3 for sip@ietf.org; Thu, 14 Jun 2007 05:33:26 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylhG-0002I9-7C for sip@ietf.org; Thu, 14 Jun 2007 05:32:57 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJM00AATD6HAC@siemenscomms.co.uk> for sip@ietf.org; Thu, 14 Jun 2007 10:32:41 +0100 (BST) Date: Thu, 14 Jun 2007 10:32:52 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? In-reply-to: A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> To: "Christer Holmberg (JO/LMF)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, Slightly aside from the main direction of the discussion, but what about security? I send my audio using SRTP, and would expect DTMF to receive exactly the same protection. The signalling may or may not be end-to-end secured, depending on which of the current and future key management methods are used. Maybe SIPS has to be used, but we all know the limitations of that (e.g., if I receive an INVITE request to my SIPS URI, can I be sure all hops are secured?). I am sure the IETF would not want to endorse a mechanism that opens up a security hole that is not present with an existing mechanism for doing the same thing (RFC 2833). John > -----Original Message----- > From: Christer Holmberg (JO/LMF) > [mailto:christer.holmberg@ericsson.com] > Sent: 14 June 2007 10:20 > To: Paul Kyzivat > Cc: SIP IETF; Dean Willis > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > Hi, > > >>I don't think an application will trigger INFOs in a spray and pray > >>matter. You will only send media server control messages if you are > >>communicating with a media server control application that > >>understands them. > > > >How does my phone know it is communicating with a media > >server that understands INFO for conveying DTMF? The thing I > >call may indicate support of INFO because it supports qsig tunneling. > > It should also indicate support (using the Accept header) of the > content-type which is used to transport the media control messages. > > >>>Before you send a DTMF/INFO, you really need to know that the > recipient understands DTMF/INFO in general and the > >>>specific encoding of DTMF in INFO that you're using (there > have been > >>>multiple encodings proposed). > >> > >>Yes, and you know that if you receive an indication from the other > party that he supports application/my-dtmf (or whatever > >value is used). > >> > >>And, if we would have standardized one encoding, maybe > there wouldn't > >>be multiple ones out there... > > > >We currently have no way to say "I support mime-type foo for > >use with disposition bar and method baz", but in reality that > >is going to be the situation. I support sdp for disposition > >"session" in the methods that convey o/a. But I don't support > >sdp in MESSAGE or INFO. I support text/plain with > content-type "render" > in MESSAGE, but not for other > >dispositions and other message types. > > You don't have any way to say "I support mime-type SDP for use with > disposition bar and method baz" either - that we specify elsewhere. > > And, if we define a DTMF mime-type, we should of course also say in > which SIP message it can be used etc. But, again, we should > not specify > the applications that are going to use it. > > Also, since INFO is not supposed to affect the SIP session, > we can also > put restrictions on which disposition values are to be used etc. > > So, of course there is some work to do, but that's not a reason to > reject something. If everything was done and ready, there would be no > need for the SIP WG :) > > >Getting an indication of support for application/my-dtmf is > >useful *if* you know that the UA sending it to you always > >uses it the same ways you do. You can only know that if you > >control it, or if all the uses of that type are standardized. > > It's up to the applications to make sure that the DTMFs are sent and > intepreted. If the receiving application has not asked for DTMFs, and > the sender still sends them, the receiver should simply discard them. > It's part of the application logic - not the SIP protocol. The SIP > protocol defines information elements to indicate what > content types you > support, what actions to take if the content type is not > supported etc. > But, again: we don't specify what the applicatons are going to do with > information. > > It's similar to when you use RFC2833 for sending DTMFs. The only thing > you do, as part of the offer/answer procedure, is agreeing that both > endpoints support RFC2833 - but you do not specify what the endpoints > are going to do with the tones, when they will be sent etc. > > >>>And beyond just understanding your encoding of DTMF/INFO, > you need to > > >>>know that the recipient you are sending it to is likely to do > >>>something useful with that INFO, and that this "something > useful" is > >>>what you intend it to do when you send it. > >> > >>Yes, but you wouldn't send it unless you have a reason to think the > >>receiver is going to do something with it, e.g. if you have > >>been asked to give your PIN code. > >> > >>I don't understand why people think that applications would start > >>sending all kind of INFOs "just for fun", without any logic > >>behind. I have never seen that happen in real world deployments. I > wouldn't > >>start sending UPDATEs and/or re-INVITEs just for fun either, > >>eventhough there is nothing preventing me from doing it. > > > >Lets go back to my phone. *It* doesn't know that I have been > >asked to give my PIN code, even though I do. All my phone > >knows is that I have pressed one of the buttons on the > >keypad. It may reasonably infer that I want *something* to be > >done with them, and probably that I want them sent to the > >other end in some way. It has no idea *how* (or *if*) the > >other end is prepared to receive them. > > I think what you are talking about is how you will design your SIP > phone. > > For example, on my table phone, if I during a call want to send DTMF > tones I have to first press one button to "active" DTMF, and then any > button I sent is sent as DTMF. If I am asked to give my PIN > code, but do > not active DTMF, nothing will happen when I press the buttons. > > On my GSM phone, however, I don't need to active DTMF. If I > am asked to > give my PIN code, I simply press buttons and they are sent as DTMF > tones. > > >For instance, it may have indicated support for a mime type > >that my phone knows how to use to encode DTMF. But its > >possible it was really trying to say that it would support > >that type in a NOTIFY (sent or received). > > IF there are missing parts in the negotiation mechanism, we > need to fix > that. > > Something like: > > Accept: application/my-dtmf;method=INFO > > OR, in the draft defining the content type, we specify that > content type > X can only be sent using this and that method. I belive we do the same > thing for SDP. > > But, so far we haven't been interested in looking into these > issues. We > just say that using INFO is against the spirit of SIP, it causes all > kind of problems etc etc. > > My intention is not to "promote" the usage of INFO. My issue > is that the > market has found and deployed an easy and effective way of > doing things > using INFO, without breaking the protocol, and what worries me is that > instead of trying to help the market (e.g. by standardizing > the content > types, providing negotiation mechanism to achieve > interoperability), and > in that way indirectly help them to come up with new SIP applications, > we simply tell them that what they are doing (and have been doing for > years) is wrong, that they are breaking SIP, etc etc etc. > > And, if we really wanted to restrict the usage of INFO, it should have > been done a long time ago - not years after the INFO RFC is published > and people have deployed usages of it. > > Anyway, I guess we can go on with this discussion forever. Maybe we > should find some time in Chicago and sit down and discuss this? > > Regards, > > Christer > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:40:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylo5-0007VE-V7; Thu, 14 Jun 2007 05:39:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hylo4-0007Qx-OM for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylo4-0007QP-DU for sip@ietf.org; Thu, 14 Jun 2007 05:39:56 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hylo2-0006WB-Pq for sip@ietf.org; Thu, 14 Jun 2007 05:39:56 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l5E9dn7e022670; Thu, 14 Jun 2007 04:39:49 -0500 (CDT) Received: from ilexadc01.ndc.lucent.com ([135.3.39.26]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 04:39:49 -0500 Received: from ilexp01.ndc.lucent.com ([135.3.39.1]) by ilexadc01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 04:39:49 -0500 Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 04:39:49 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:39:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 14 Jun 2007 11:39:44 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> In-Reply-To: <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Thread-Index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQA== References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> From: "DRAGE, Keith \(Keith\)" To: "Christer Holmberg \(JO/LMF\)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 14 Jun 2007 09:39:45.0902 (UTC) FILETIME=[F17268E0:01C7AE67] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org You appear to be questioning whether the solution was adopted. The = minutes state: ------------------------------------------------------------------- Topic: GRUU and Supporting Drafts =20 Led by Jonathan Rosenberg =20 Slides included in proceedings=20 Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 Change since last version reviewed. Issue: GRUU subtype names. The room demonstrated a slight preference for the names used in -11 over known alternatives, but nobody seems particularly enamored with these names and the floor remains open to suggestions. Discussion on ua-loose-route draft deferred to next session. Session 2: Friday 0900-1130 Grand Ballroom C Topic: UA-loose-route, continued from previous session. Consensus noted that we do need some sort of solution for the general problem of delivery of URI parameters across contact-routing operations. Issue: Concerns raised about backward compatibility. Noted that compliant P-CSCF should be OK. Suggested that we have a design team revisit call-flows and analyze for backward compatibility issues. Issue: Does GRUU normatively depend on this work? Resolved: GRUU does not reference this document. However, some participants feel it should, as the benefit of GRUU cannot be fully recognized in the absence of this specification. The chairs asked for a hum, and the consensus of the room is that GRUU and ua-loose-route can proceed independently. Question: Adopt this draft as baseline text for a WG effort, should the ADs approve the milestone? Consensus to adopt noted by chairs. To-do: Chairs to work with AD to set new milestone. ---------------------------------------------------------------------- The minutes quite clearly say "Adopt this draft as baseline text for a = WG effort" and given that the charter item now exists, then I believe = that we are entitled to call for the editor (Jonathan) to submit the = current text as draft-ietf-sip-ua-loose-route. I agree the file name says loose-route, but I don'y think we should = change that. After all, we lose that filename when it gets published as = an RFC anyway. The charter item states Dec 2007 Delivering request-URI and parameters to UAS via proxy to = WGLC =20 Feb 2008 Delivering request-URI and parameters to UAS via proxy to = IESG (PS) =20 I assume that you are OK with this. What I would suggest is that you address specific comments to the title = of the deliverable: Applying Loose Routing to Session Initiation Protocol (SIP) User Agents = (UA) And to the abstract: Abstract A key part of the behavior of the Session Initiation Protocol (SIP) is that SIP proxies rewrite the Request-URI as a request moves throughout the network. Over the years, experience has shown this to be problematic. It makes it difficult to use Request URI for service invocation, complicates emergency services, makes it more complex to support aliases, and so on. Architecturally, it confounds the concepts of address and route. This document proposes to change this through a new mechanism called UA loose routing. As you think appropriate to your concerns. Alternatively, if you (or indeed any other SIP WG member) do have a = completely different solution, then there is still time to post an = individual draft or post a skeleton of a mechanism to the list. Regards Keith > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, June 13, 2007 8:52 PM > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing >=20 >=20 > Hi, >=20 > We can call it loose route if we want, but I think the=20 > initial focus should be the problem we are going to solve (I=20 > don't think we agreed on a specific solution at #67), and we=20 > should look into alternative solutions (the draft does that=20 > in some extent, but other possible alternatives have also=20 > been mentioned). >=20 > Or, do you prefer to have separate drafts describing=20 > alternative solutions for the problem? >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 13. kes=E4kuuta 2007 22:25 > > To: Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing > >=20 > > (As WG chair) > >=20 > > As well as agreeing to charter the item, we actually agreed=20 > at IETF#67=20 > > that this draft was a suitable candidate to fulfil that=20 > charter item. > >=20 > > Therefore unless issues are raised with this, I would request the=20 > > editor (as Jonathan is editor) to submit the next version of this=20 > > document as draft-ietf-sip-ua-loose-route-00. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > To: IETF SIP List > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards compatibility > > >=20 > > > I've recently revised my draft on UA loose routing. You can > > pick it up > > > here: > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > se-route-01.txt > > >=20 > > > This draft is meant to fulfill one of our charter items: > > > Feb 2008 Delivering request-URI and parameters=20 > > > to UAS via proxy to > > > IESG (PS) > > >=20 > > > As folks may recall, the GRUU spec used to have these=20 > things called=20 > > > grids, which allowed a UA to add its own parameters to the > > GRUU before > > > handing it out. Several GRUU revisions back, this function > > got yanked > > > because it was recognized that the problem was more general > > than GRUU, > > > and would be useful for AOR as well. > > >=20 > > > Two IETFs back I presented this draft briefly during a=20 > SIP session.=20 > > > There was a lot of interest and people liked it architecturally,=20 > > > however there were two open issues that needed to get > > resolved. This > > > mail is meant to start discussion on one of them - backwards=20 > > > compatibility. > > >=20 > > > THe mechanism basically changes the way proxies handle requests.=20 > > > Instead of rewriting the request URI for out-of-dialog requests,=20 > > > they'll push a route header and leave the r-uri alone. This > > allows the > > > original R-URI and any parameters it contains to get > > delivered to the > > > UAS. > > >=20 > > > So, the main issue is, what kinds of backwards > > compatibility problems > > > will this cause. The draft provides a basic mechanism=20 > whereby a UA=20 > > > includes an option tag in the REGISTER, and the registrar=20 > indicates=20 > > > that it is using this mechanism or not. So we can negotiate this=20 > > > between a UA and registrar easily. Now, the problem is with=20 > > > intermediate proxies. If there is an edge proxy between the > > UA and its > > > registrar, it will now see requests targeted to the UA, > > which contain > > > a Route header beyond itself, even though it thinks its the > > edge proxy > > > and the last point of contact before the UA. Technically, > > if this edge > > > proxy is compliant to rfc3261 it would work. However, the > > question is > > > whether proxies in the wild would properly work in this case. > > >=20 > > > If folks can comment based on their own products, or their=20 > > > experiences, on whether they think this would work, or > > concerns they > > > have, that would be great. THere are solutions that would > > allow us to > > > disable the mechanism when intermediate proxies don't > > support it, but > > > they are more complex and I'd rather avoid it. > > >=20 > > > THanks, > > > Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ=20 > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylpS-0000gl-T0; Thu, 14 Jun 2007 05:41:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HylpR-0000dE-R3 for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HylpR-0000Zi-D4 for sip@ietf.org; Thu, 14 Jun 2007 05:41:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HylpQ-0006eh-HO for sip@ietf.org; Thu, 14 Jun 2007 05:41:21 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E85E5212BA; Thu, 14 Jun 2007 11:41:19 +0200 (CEST) X-AuditID: c1b4fb3e-b0e79bb0000007e1-79-46710d3fb705 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C729921177; Thu, 14 Jun 2007 11:41:19 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:41:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 14 Jun 2007 11:41:18 +0200 Message-ID: <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwA== References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" X-OriginalArrivalTime: 14 Jun 2007 09:41:19.0271 (UTC) FILETIME=[29196370:01C7AE68] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John, I hear what you are saying, but I don't see how this is specific to DTMF = and INFO.=20 Doesn't this affect all I kind of sensitive information that you want to = transport over SIP? Regards, Christer =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: 14. kes=E4kuuta 2007 12:33 > To: Christer Holmberg (JO/LMF) > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > Christer, >=20 > Slightly aside from the main direction of the discussion, but=20 > what about security? I send my audio using SRTP, and would=20 > expect DTMF to receive exactly the same protection. The=20 > signalling may or may not be end-to-end secured, depending on=20 > which of the current and future key management methods are=20 > used. Maybe SIPS has to be used, but we all know the=20 > limitations of that (e.g., if I receive an INVITE request to=20 > my SIPS URI, can I be sure all hops are secured?). I am sure=20 > the IETF would not want to endorse a mechanism that opens up=20 > a security hole that is not present with an existing=20 > mechanism for doing the same thing (RFC 2833). >=20 > John >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 14 June 2007 10:20 > > To: Paul Kyzivat > > Cc: SIP IETF; Dean Willis > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > >=20 > > Hi, > >=20 > > >>I don't think an application will trigger INFOs in a=20 > spray and pray=20 > > >>matter. You will only send media server control messages=20 > if you are=20 > > >>communicating with a media server control application that=20 > > >>understands them. > > >=20 > > >How does my phone know it is communicating with a media=20 > server that=20 > > >understands INFO for conveying DTMF? The thing I call may indicate=20 > > >support of INFO because it supports qsig tunneling. > >=20 > > It should also indicate support (using the Accept header) of the=20 > > content-type which is used to transport the media control messages. > > =20 > > >>>Before you send a DTMF/INFO, you really need to know that the > > recipient understands DTMF/INFO in general and the > > >>>specific encoding of DTMF in INFO that you're using (there > > have been > > >>>multiple encodings proposed). > > >>=20 > > >>Yes, and you know that if you receive an indication from the other > > party that he supports application/my-dtmf (or whatever > > >value is used). > > >>=20 > > >>And, if we would have standardized one encoding, maybe > > there wouldn't > > >>be multiple ones out there... > > >=20 > > >We currently have no way to say "I support mime-type foo=20 > for use with=20 > > >disposition bar and method baz", but in reality that is=20 > going to be=20 > > >the situation. I support sdp for disposition "session" in=20 > the methods=20 > > >that convey o/a. But I don't support sdp in MESSAGE or INFO. I=20 > > >support text/plain with > > content-type "render" > > in MESSAGE, but not for other > > >dispositions and other message types. > >=20 > > You don't have any way to say "I support mime-type SDP for use with=20 > > disposition bar and method baz" either - that we specify elsewhere. > >=20 > > And, if we define a DTMF mime-type, we should of course also say in=20 > > which SIP message it can be used etc. But, again, we should not=20 > > specify the applications that are going to use it. > >=20 > > Also, since INFO is not supposed to affect the SIP session, we can=20 > > also put restrictions on which disposition values are to be=20 > used etc. > >=20 > > So, of course there is some work to do, but that's not a reason to=20 > > reject something. If everything was done and ready, there=20 > would be no=20 > > need for the SIP WG :) > >=20 > > >Getting an indication of support for application/my-dtmf is useful=20 > > >*if* you know that the UA sending it to you always uses it=20 > the same=20 > > >ways you do. You can only know that if you control it, or=20 > if all the=20 > > >uses of that type are standardized. > >=20 > > It's up to the applications to make sure that the DTMFs are=20 > sent and=20 > > intepreted. If the receiving application has not asked for=20 > DTMFs, and=20 > > the sender still sends them, the receiver should simply=20 > discard them. > > It's part of the application logic - not the SIP protocol. The SIP=20 > > protocol defines information elements to indicate what=20 > content types=20 > > you support, what actions to take if the content type is=20 > not supported=20 > > etc. > > But, again: we don't specify what the applicatons are going=20 > to do with=20 > > information. > >=20 > > It's similar to when you use RFC2833 for sending DTMFs. The=20 > only thing=20 > > you do, as part of the offer/answer procedure, is agreeing=20 > that both=20 > > endpoints support RFC2833 - but you do not specify what the=20 > endpoints=20 > > are going to do with the tones, when they will be sent etc. > >=20 > > >>>And beyond just understanding your encoding of DTMF/INFO, > > you need to > >=20 > > >>>know that the recipient you are sending it to is likely to do=20 > > >>>something useful with that INFO, and that this "something > > useful" is > > >>>what you intend it to do when you send it. > > >> > > >>Yes, but you wouldn't send it unless you have a reason to=20 > think the=20 > > >>receiver is going to do something with it, e.g. if you have been=20 > > >>asked to give your PIN code. > > >>=20 > > >>I don't understand why people think that applications would start=20 > > >>sending all kind of INFOs "just for fun", without any=20 > logic behind.=20 > > >>I have never seen that happen in real world deployments. I > > wouldn't > > >>start sending UPDATEs and/or re-INVITEs just for fun either,=20 > > >>eventhough there is nothing preventing me from doing it. > > >=20 > > >Lets go back to my phone. *It* doesn't know that I have=20 > been asked to=20 > > >give my PIN code, even though I do. All my phone knows is=20 > that I have=20 > > >pressed one of the buttons on the keypad. It may reasonably infer=20 > > >that I want *something* to be done with them, and probably that I=20 > > >want them sent to the other end in some way. It has no=20 > idea *how* (or=20 > > >*if*) the other end is prepared to receive them. > >=20 > > I think what you are talking about is how you will design your SIP=20 > > phone. > >=20 > > For example, on my table phone, if I during a call want to=20 > send DTMF=20 > > tones I have to first press one button to "active" DTMF,=20 > and then any=20 > > button I sent is sent as DTMF. If I am asked to give my PIN=20 > code, but=20 > > do not active DTMF, nothing will happen when I press the buttons. > >=20 > > On my GSM phone, however, I don't need to active DTMF. If I=20 > am asked=20 > > to give my PIN code, I simply press buttons and they are=20 > sent as DTMF=20 > > tones. > >=20 > > >For instance, it may have indicated support for a mime=20 > type that my=20 > > >phone knows how to use to encode DTMF. But its possible it=20 > was really=20 > > >trying to say that it would support that type in a NOTIFY (sent or=20 > > >received). > >=20 > > IF there are missing parts in the negotiation mechanism, we need to=20 > > fix that. > >=20 > > Something like: > >=20 > > Accept: application/my-dtmf;method=3DINFO > >=20 > > OR, in the draft defining the content type, we specify that content=20 > > type X can only be sent using this and that method. I=20 > belive we do the=20 > > same thing for SDP. > >=20 > > But, so far we haven't been interested in looking into=20 > these issues.=20 > > We just say that using INFO is against the spirit of SIP, it causes=20 > > all kind of problems etc etc. > >=20 > > My intention is not to "promote" the usage of INFO. My=20 > issue is that=20 > > the market has found and deployed an easy and effective way=20 > of doing=20 > > things using INFO, without breaking the protocol, and what=20 > worries me=20 > > is that instead of trying to help the market (e.g. by standardizing=20 > > the content types, providing negotiation mechanism to achieve=20 > > interoperability), and in that way indirectly help them to come up=20 > > with new SIP applications, we simply tell them that what they are=20 > > doing (and have been doing for > > years) is wrong, that they are breaking SIP, etc etc etc. > >=20 > > And, if we really wanted to restrict the usage of INFO, it=20 > should have=20 > > been done a long time ago - not years after the INFO RFC is=20 > published=20 > > and people have deployed usages of it. > >=20 > > Anyway, I guess we can go on with this discussion forever. Maybe we=20 > > should find some time in Chicago and sit down and discuss this? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylz0-0004wB-2L; Thu, 14 Jun 2007 05:51:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hylyy-0004vs-Bc for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylyy-0004vf-1m for sip@ietf.org; Thu, 14 Jun 2007 05:51:12 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hylyw-0002Iq-1Y for sip@ietf.org; Thu, 14 Jun 2007 05:51:12 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6865E20A90; Thu, 14 Jun 2007 11:51:09 +0200 (CEST) X-AuditID: c1b4fb3c-b0e80bb0000007e1-7a-46710f8df4fb Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 42D4720A8A; Thu, 14 Jun 2007 11:51:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:51:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 14 Jun 2007 11:51:08 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing thread-index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQAAAiGYQ References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "DRAGE, Keith (Keith)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 14 Jun 2007 09:51:08.0988 (UTC) FILETIME=[88990FC0:01C7AE69] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Keith, The text you sent says: "Consensus noted that we do need some sort of solution for the general = problem of delivery of URI parameters across contact-routing = operations." I have no problems with that.=20 I also have no problem with using Jonathan's draft as base line, because = the draft discusses the problem in a good way. But, still: as the text says, the agreement was to come up with SOME = SORT OF SOLUTION, which to me does not mean that we have agreed to adopt = the specific solution in Jonathan's draft. We should also be "allowed" = to discuss alternative solutions, whether they are based on = P-Called-Party, some other header, some URI parameter, or whatever... = Maybe those alternative solutions do not work, and then we should = describe that (as Jonathan has done for the To header- and History = header alternatives). Regards, Christer =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: 14. kes=E4kuuta 2007 12:40 > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing >=20 > You appear to be questioning whether the solution was=20 > adopted. The minutes state: >=20 > ------------------------------------------------------------------- > Topic: GRUU and Supporting Drafts =20 > Led by Jonathan Rosenberg > Slides included in proceedings > Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 >=20 > Change since last version reviewed. >=20 > Issue: GRUU subtype names. The room demonstrated a slight=20 > preference for the names used in -11 over known alternatives,=20 > but nobody seems particularly enamored with these names and=20 > the floor remains open to suggestions. >=20 > Discussion on ua-loose-route draft deferred to next session. >=20 >=20 > Session 2: Friday 0900-1130 Grand Ballroom C >=20 >=20 > Topic: UA-loose-route, continued from previous session. >=20 > Consensus noted that we do need some sort of solution for the=20 > general problem of delivery of URI parameters across=20 > contact-routing operations. >=20 > Issue: Concerns raised about backward compatibility. Noted=20 > that compliant P-CSCF should be OK. Suggested that we have a=20 > design team revisit call-flows and analyze for backward=20 > compatibility issues. >=20 > Issue: Does GRUU normatively depend on this work? Resolved:=20 > GRUU does not reference this document. However, some=20 > participants feel it should, as the benefit of GRUU cannot be=20 > fully recognized in the absence of this specification. The=20 > chairs asked for a hum, and the consensus of the room is that=20 > GRUU and ua-loose-route can proceed independently. >=20 > Question: Adopt this draft as baseline text for a WG effort,=20 > should the ADs approve the milestone? Consensus to adopt=20 > noted by chairs. To-do: Chairs to work with AD to set new milestone. > ---------------------------------------------------------------------- >=20 > The minutes quite clearly say "Adopt this draft as baseline=20 > text for a WG effort" and given that the charter item now=20 > exists, then I believe that we are entitled to call for the=20 > editor (Jonathan) to submit the current text as=20 > draft-ietf-sip-ua-loose-route. >=20 > I agree the file name says loose-route, but I don'y think we=20 > should change that. After all, we lose that filename when it=20 > gets published as an RFC anyway. >=20 > The charter item states >=20 > Dec 2007 Delivering request-URI and parameters to UAS via=20 > proxy to WGLC =20 > Feb 2008 Delivering request-URI and parameters to UAS via=20 > proxy to IESG (PS) =20 >=20 > I assume that you are OK with this. >=20 > What I would suggest is that you address specific comments to=20 > the title of the deliverable: >=20 > Applying Loose Routing to Session Initiation Protocol=20 > (SIP) User Agents (UA) >=20 > And to the abstract: >=20 > Abstract >=20 > A key part of the behavior of the Session Initiation Protocol (SIP) > is that SIP proxies rewrite the Request-URI as a request moves > throughout the network. Over the years, experience has=20 > shown this to > be problematic. It makes it difficult to use Request URI=20 > for service > invocation, complicates emergency services, makes it more=20 > complex to > support aliases, and so on. Architecturally, it confounds the > concepts of address and route. This document proposes to=20 > change this > through a new mechanism called UA loose routing. >=20 > As you think appropriate to your concerns. >=20 > Alternatively, if you (or indeed any other SIP WG member) do=20 > have a completely different solution, then there is still=20 > time to post an individual draft or post a skeleton of a=20 > mechanism to the list. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 13, 2007 8:52 PM > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing > >=20 > >=20 > > Hi, > >=20 > > We can call it loose route if we want, but I think the=20 > initial focus=20 > > should be the problem we are going to solve (I don't think=20 > we agreed=20 > > on a specific solution at #67), and we should look into alternative=20 > > solutions (the draft does that in some extent, but other possible=20 > > alternatives have also been mentioned). > >=20 > > Or, do you prefer to have separate drafts describing alternative=20 > > solutions for the problem? > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: 13. kes=E4kuuta 2007 22:25 > > > To: Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] UA Loose Routing > > >=20 > > > (As WG chair) > > >=20 > > > As well as agreeing to charter the item, we actually agreed > > at IETF#67 > > > that this draft was a suitable candidate to fulfil that > > charter item. > > >=20 > > > Therefore unless issues are raised with this, I would request the=20 > > > editor (as Jonathan is editor) to submit the next version of this=20 > > > document as draft-ietf-sip-ua-loose-route-00. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > > To: IETF SIP List > > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards=20 > compatibility > > > >=20 > > > > I've recently revised my draft on UA loose routing. You can > > > pick it up > > > > here: > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > > se-route-01.txt > > > >=20 > > > > This draft is meant to fulfill one of our charter items: > > > > Feb 2008 Delivering request-URI and parameters=20 > > > > to UAS via proxy to > > > > IESG (PS) > > > >=20 > > > > As folks may recall, the GRUU spec used to have these > > things called > > > > grids, which allowed a UA to add its own parameters to the > > > GRUU before > > > > handing it out. Several GRUU revisions back, this function > > > got yanked > > > > because it was recognized that the problem was more general > > > than GRUU, > > > > and would be useful for AOR as well. > > > >=20 > > > > Two IETFs back I presented this draft briefly during a > > SIP session.=20 > > > > There was a lot of interest and people liked it=20 > architecturally,=20 > > > > however there were two open issues that needed to get > > > resolved. This > > > > mail is meant to start discussion on one of them - backwards=20 > > > > compatibility. > > > >=20 > > > > THe mechanism basically changes the way proxies handle=20 > requests.=20 > > > > Instead of rewriting the request URI for out-of-dialog=20 > requests,=20 > > > > they'll push a route header and leave the r-uri alone. This > > > allows the > > > > original R-URI and any parameters it contains to get > > > delivered to the > > > > UAS. > > > >=20 > > > > So, the main issue is, what kinds of backwards > > > compatibility problems > > > > will this cause. The draft provides a basic mechanism > > whereby a UA > > > > includes an option tag in the REGISTER, and the registrar > > indicates > > > > that it is using this mechanism or not. So we can=20 > negotiate this=20 > > > > between a UA and registrar easily. Now, the problem is with=20 > > > > intermediate proxies. If there is an edge proxy between the > > > UA and its > > > > registrar, it will now see requests targeted to the UA, > > > which contain > > > > a Route header beyond itself, even though it thinks its the > > > edge proxy > > > > and the last point of contact before the UA. Technically, > > > if this edge > > > > proxy is compliant to rfc3261 it would work. However, the > > > question is > > > > whether proxies in the wild would properly work in this case. > > > >=20 > > > > If folks can comment based on their own products, or their=20 > > > > experiences, on whether they think this would work, or > > > concerns they > > > > have, that would be great. THere are solutions that would > > > allow us to > > > > disable the mechanism when intermediate proxies don't > > > support it, but > > > > they are more complex and I'd rather avoid it. > > > >=20 > > > > THanks, > > > > Jonathan R. > > > > --=20 > > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > > Cisco Fellow Parsippany, NJ=20 > > > > 07054-2711 > > > > Cisco Systems > > > > jdrosen@cisco.com FAX: =20 > > (973) 952-5050 > > > > http://www.jdrosen.net PHONE:=20 > > (973) 952-5000 > > > > http://www.cisco.com > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym1G-0007Gu-It; Thu, 14 Jun 2007 05:53:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hym1E-0007GY-RM for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym1E-0007GQ-Hc for sip@ietf.org; Thu, 14 Jun 2007 05:53:32 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hym1D-0003JM-IT for sip@ietf.org; Thu, 14 Jun 2007 05:53:32 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJM00G3LE4V89@siemenscomms.co.uk> for sip@ietf.org; Thu, 14 Jun 2007 10:53:19 +0100 (BST) Date: Thu, 14 Jun 2007 10:53:29 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? In-reply-to: A <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> To: "Christer Holmberg (JO/LMF)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E677@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwAAAf5Lg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, Yes, it affects all information, but in the case of DTMF we already have = a mechanism for securing it, SRTP. So why attempt to standardise a new = mechanism for transporting DTMF that introduces security issues that are = already solved with the existing mechanism? John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 14 June 2007 10:41 > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi John, >=20 > I hear what you are saying, but I don't see how this is=20 > specific to DTMF and INFO.=20 >=20 > Doesn't this affect all I kind of sensitive information that=20 > you want to transport over SIP? >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > > Sent: 14. kes=E4kuuta 2007 12:33 > > To: Christer Holmberg (JO/LMF) > > Cc: SIP IETF > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > > Christer, > >=20 > > Slightly aside from the main direction of the discussion, but=20 > > what about security? I send my audio using SRTP, and would=20 > > expect DTMF to receive exactly the same protection. The=20 > > signalling may or may not be end-to-end secured, depending on=20 > > which of the current and future key management methods are=20 > > used. Maybe SIPS has to be used, but we all know the=20 > > limitations of that (e.g., if I receive an INVITE request to=20 > > my SIPS URI, can I be sure all hops are secured?). I am sure=20 > > the IETF would not want to endorse a mechanism that opens up=20 > > a security hole that is not present with an existing=20 > > mechanism for doing the same thing (RFC 2833). > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 14 June 2007 10:20 > > > To: Paul Kyzivat > > > Cc: SIP IETF; Dean Willis > > > Subject: RE: [Sip] INFO message belongs only to INVITE=20 > dialog usage? > > >=20 > > >=20 > > > Hi, > > >=20 > > > >>I don't think an application will trigger INFOs in a=20 > > spray and pray=20 > > > >>matter. You will only send media server control messages=20 > > if you are=20 > > > >>communicating with a media server control application that=20 > > > >>understands them. > > > >=20 > > > >How does my phone know it is communicating with a media=20 > > server that=20 > > > >understands INFO for conveying DTMF? The thing I call=20 > may indicate=20 > > > >support of INFO because it supports qsig tunneling. > > >=20 > > > It should also indicate support (using the Accept header) of the=20 > > > content-type which is used to transport the media control=20 > messages. > > > =20 > > > >>>Before you send a DTMF/INFO, you really need to know that the > > > recipient understands DTMF/INFO in general and the > > > >>>specific encoding of DTMF in INFO that you're using (there > > > have been > > > >>>multiple encodings proposed). > > > >>=20 > > > >>Yes, and you know that if you receive an indication=20 > from the other > > > party that he supports application/my-dtmf (or whatever > > > >value is used). > > > >>=20 > > > >>And, if we would have standardized one encoding, maybe > > > there wouldn't > > > >>be multiple ones out there... > > > >=20 > > > >We currently have no way to say "I support mime-type foo=20 > > for use with=20 > > > >disposition bar and method baz", but in reality that is=20 > > going to be=20 > > > >the situation. I support sdp for disposition "session" in=20 > > the methods=20 > > > >that convey o/a. But I don't support sdp in MESSAGE or INFO. I=20 > > > >support text/plain with > > > content-type "render" > > > in MESSAGE, but not for other > > > >dispositions and other message types. > > >=20 > > > You don't have any way to say "I support mime-type SDP=20 > for use with=20 > > > disposition bar and method baz" either - that we specify=20 > elsewhere. > > >=20 > > > And, if we define a DTMF mime-type, we should of course=20 > also say in=20 > > > which SIP message it can be used etc. But, again, we should not=20 > > > specify the applications that are going to use it. > > >=20 > > > Also, since INFO is not supposed to affect the SIP=20 > session, we can=20 > > > also put restrictions on which disposition values are to be=20 > > used etc. > > >=20 > > > So, of course there is some work to do, but that's not a=20 > reason to=20 > > > reject something. If everything was done and ready, there=20 > > would be no=20 > > > need for the SIP WG :) > > >=20 > > > >Getting an indication of support for application/my-dtmf=20 > is useful=20 > > > >*if* you know that the UA sending it to you always uses it=20 > > the same=20 > > > >ways you do. You can only know that if you control it, or=20 > > if all the=20 > > > >uses of that type are standardized. > > >=20 > > > It's up to the applications to make sure that the DTMFs are=20 > > sent and=20 > > > intepreted. If the receiving application has not asked for=20 > > DTMFs, and=20 > > > the sender still sends them, the receiver should simply=20 > > discard them. > > > It's part of the application logic - not the SIP=20 > protocol. The SIP=20 > > > protocol defines information elements to indicate what=20 > > content types=20 > > > you support, what actions to take if the content type is=20 > > not supported=20 > > > etc. > > > But, again: we don't specify what the applicatons are going=20 > > to do with=20 > > > information. > > >=20 > > > It's similar to when you use RFC2833 for sending DTMFs. The=20 > > only thing=20 > > > you do, as part of the offer/answer procedure, is agreeing=20 > > that both=20 > > > endpoints support RFC2833 - but you do not specify what the=20 > > endpoints=20 > > > are going to do with the tones, when they will be sent etc. > > >=20 > > > >>>And beyond just understanding your encoding of DTMF/INFO, > > > you need to > > >=20 > > > >>>know that the recipient you are sending it to is likely to do=20 > > > >>>something useful with that INFO, and that this "something > > > useful" is > > > >>>what you intend it to do when you send it. > > > >> > > > >>Yes, but you wouldn't send it unless you have a reason to=20 > > think the=20 > > > >>receiver is going to do something with it, e.g. if you=20 > have been=20 > > > >>asked to give your PIN code. > > > >>=20 > > > >>I don't understand why people think that applications=20 > would start=20 > > > >>sending all kind of INFOs "just for fun", without any=20 > > logic behind.=20 > > > >>I have never seen that happen in real world deployments. I > > > wouldn't > > > >>start sending UPDATEs and/or re-INVITEs just for fun either,=20 > > > >>eventhough there is nothing preventing me from doing it. > > > >=20 > > > >Lets go back to my phone. *It* doesn't know that I have=20 > > been asked to=20 > > > >give my PIN code, even though I do. All my phone knows is=20 > > that I have=20 > > > >pressed one of the buttons on the keypad. It may=20 > reasonably infer=20 > > > >that I want *something* to be done with them, and=20 > probably that I=20 > > > >want them sent to the other end in some way. It has no=20 > > idea *how* (or=20 > > > >*if*) the other end is prepared to receive them. > > >=20 > > > I think what you are talking about is how you will design=20 > your SIP=20 > > > phone. > > >=20 > > > For example, on my table phone, if I during a call want to=20 > > send DTMF=20 > > > tones I have to first press one button to "active" DTMF,=20 > > and then any=20 > > > button I sent is sent as DTMF. If I am asked to give my PIN=20 > > code, but=20 > > > do not active DTMF, nothing will happen when I press the buttons. > > >=20 > > > On my GSM phone, however, I don't need to active DTMF. If I=20 > > am asked=20 > > > to give my PIN code, I simply press buttons and they are=20 > > sent as DTMF=20 > > > tones. > > >=20 > > > >For instance, it may have indicated support for a mime=20 > > type that my=20 > > > >phone knows how to use to encode DTMF. But its possible it=20 > > was really=20 > > > >trying to say that it would support that type in a=20 > NOTIFY (sent or=20 > > > >received). > > >=20 > > > IF there are missing parts in the negotiation mechanism,=20 > we need to=20 > > > fix that. > > >=20 > > > Something like: > > >=20 > > > Accept: application/my-dtmf;method=3DINFO > > >=20 > > > OR, in the draft defining the content type, we specify=20 > that content=20 > > > type X can only be sent using this and that method. I=20 > > belive we do the=20 > > > same thing for SDP. > > >=20 > > > But, so far we haven't been interested in looking into=20 > > these issues.=20 > > > We just say that using INFO is against the spirit of SIP,=20 > it causes=20 > > > all kind of problems etc etc. > > >=20 > > > My intention is not to "promote" the usage of INFO. My=20 > > issue is that=20 > > > the market has found and deployed an easy and effective way=20 > > of doing=20 > > > things using INFO, without breaking the protocol, and what=20 > > worries me=20 > > > is that instead of trying to help the market (e.g. by=20 > standardizing=20 > > > the content types, providing negotiation mechanism to achieve=20 > > > interoperability), and in that way indirectly help them=20 > to come up=20 > > > with new SIP applications, we simply tell them that what they are=20 > > > doing (and have been doing for > > > years) is wrong, that they are breaking SIP, etc etc etc. > > >=20 > > > And, if we really wanted to restrict the usage of INFO, it=20 > > should have=20 > > > been done a long time ago - not years after the INFO RFC is=20 > > published=20 > > > and people have deployed usages of it. > > >=20 > > > Anyway, I guess we can go on with this discussion=20 > forever. Maybe we=20 > > > should find some time in Chicago and sit down and discuss this? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 05:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym3h-0003GT-FM; Thu, 14 Jun 2007 05:56:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hym3f-0003GN-G8 for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 05:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym3f-0003GF-6M for sip@ietf.org; Thu, 14 Jun 2007 05:56:03 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hym3d-0004nj-Iz for sip@ietf.org; Thu, 14 Jun 2007 05:56:03 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l5E9twxk028360; Thu, 14 Jun 2007 04:55:58 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 04:55:58 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 11:55:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 14 Jun 2007 11:55:44 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> In-Reply-To: <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing Thread-Index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQAAAiGYQAABcmGA= References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> From: "DRAGE, Keith \(Keith\)" To: "Christer Holmberg \(JO/LMF\)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 14 Jun 2007 09:55:46.0126 (UTC) FILETIME=[2DC8F6E0:01C7AE6A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org It is entirely appropriate at this stage to put forward alternatives. It = is even more appropriate to do it now rather than in 6 months time. However please do not expect the editor to elaborate them. If the WG has = ideas, send text, either by individual author drafts, or by the mailing = list.=20 Regards Keith > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Thursday, June 14, 2007 10:51 AM > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing >=20 >=20 > Hi Keith, >=20 > The text you sent says: >=20 > "Consensus noted that we do need some sort of solution for=20 > the general problem of delivery of URI parameters across=20 > contact-routing operations." >=20 > I have no problems with that.=20 >=20 > I also have no problem with using Jonathan's draft as base=20 > line, because the draft discusses the problem in a good way. >=20 > But, still: as the text says, the agreement was to come up=20 > with SOME SORT OF SOLUTION, which to me does not mean that we=20 > have agreed to adopt the specific solution in Jonathan's=20 > draft. We should also be "allowed" to discuss alternative=20 > solutions, whether they are based on P-Called-Party, some=20 > other header, some URI parameter, or whatever... Maybe those=20 > alternative solutions do not work, and then we should=20 > describe that (as Jonathan has done for the To header- and=20 > History header alternatives). >=20 > Regards, >=20 > Christer >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: 14. kes=E4kuuta 2007 12:40 > > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing > >=20 > > You appear to be questioning whether the solution was adopted. The=20 > > minutes state: > >=20 > > ------------------------------------------------------------------- > > Topic: GRUU and Supporting Drafts =20 > > Led by Jonathan Rosenberg > > Slides included in proceedings > > Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > >=20 > > Change since last version reviewed. > >=20 > > Issue: GRUU subtype names. The room demonstrated a slight=20 > preference=20 > > for the names used in -11 over known alternatives, but nobody seems=20 > > particularly enamored with these names and the floor=20 > remains open to=20 > > suggestions. > >=20 > > Discussion on ua-loose-route draft deferred to next session. > >=20 > >=20 > > Session 2: Friday 0900-1130 Grand Ballroom C > >=20 > >=20 > > Topic: UA-loose-route, continued from previous session. > >=20 > > Consensus noted that we do need some sort of solution for=20 > the general=20 > > problem of delivery of URI parameters across contact-routing=20 > > operations. > >=20 > > Issue: Concerns raised about backward compatibility. Noted that=20 > > compliant P-CSCF should be OK. Suggested that we have a=20 > design team=20 > > revisit call-flows and analyze for backward compatibility issues. > >=20 > > Issue: Does GRUU normatively depend on this work? Resolved:=20 > > GRUU does not reference this document. However, some=20 > participants feel=20 > > it should, as the benefit of GRUU cannot be fully recognized in the=20 > > absence of this specification. The chairs asked for a hum, and the=20 > > consensus of the room is that GRUU and ua-loose-route can proceed=20 > > independently. > >=20 > > Question: Adopt this draft as baseline text for a WG effort, should=20 > > the ADs approve the milestone? Consensus to adopt noted by chairs.=20 > > To-do: Chairs to work with AD to set new milestone. > >=20 > ---------------------------------------------------------------------- > >=20 > > The minutes quite clearly say "Adopt this draft as baseline=20 > text for a=20 > > WG effort" and given that the charter item now exists, then=20 > I believe=20 > > that we are entitled to call for the editor (Jonathan) to=20 > submit the=20 > > current text as draft-ietf-sip-ua-loose-route. > >=20 > > I agree the file name says loose-route, but I don'y think we should=20 > > change that. After all, we lose that filename when it gets=20 > published=20 > > as an RFC anyway. > >=20 > > The charter item states > >=20 > > Dec 2007 Delivering request-URI and parameters to UAS via=20 > > proxy to WGLC =20 > > Feb 2008 Delivering request-URI and parameters to UAS via=20 > > proxy to IESG (PS) =20 > >=20 > > I assume that you are OK with this. > >=20 > > What I would suggest is that you address specific comments to the=20 > > title of the deliverable: > >=20 > > Applying Loose Routing to Session Initiation Protocol > > (SIP) User Agents (UA) > >=20 > > And to the abstract: > >=20 > > Abstract > >=20 > > A key part of the behavior of the Session Initiation=20 > Protocol (SIP) > > is that SIP proxies rewrite the Request-URI as a request moves > > throughout the network. Over the years, experience has=20 > shown this=20 > > to > > be problematic. It makes it difficult to use Request URI for=20 > > service > > invocation, complicates emergency services, makes it=20 > more complex=20 > > to > > support aliases, and so on. Architecturally, it confounds the > > concepts of address and route. This document proposes to change=20 > > this > > through a new mechanism called UA loose routing. > >=20 > > As you think appropriate to your concerns. > >=20 > > Alternatively, if you (or indeed any other SIP WG member) do have a=20 > > completely different solution, then there is still time to post an=20 > > individual draft or post a skeleton of a mechanism to the list. > >=20 > > Regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Wednesday, June 13, 2007 8:52 PM > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] UA Loose Routing > > >=20 > > >=20 > > > Hi, > > >=20 > > > We can call it loose route if we want, but I think the > > initial focus > > > should be the problem we are going to solve (I don't think > > we agreed > > > on a specific solution at #67), and we should look into=20 > alternative=20 > > > solutions (the draft does that in some extent, but other possible=20 > > > alternatives have also been mentioned). > > >=20 > > > Or, do you prefer to have separate drafts describing alternative=20 > > > solutions for the problem? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: 13. kes=E4kuuta 2007 22:25 > > > > To: Jonathan Rosenberg; IETF SIP List > > > > Subject: RE: [Sip] UA Loose Routing > > > >=20 > > > > (As WG chair) > > > >=20 > > > > As well as agreeing to charter the item, we actually agreed > > > at IETF#67 > > > > that this draft was a suitable candidate to fulfil that > > > charter item. > > > >=20 > > > > Therefore unless issues are raised with this, I would=20 > request the=20 > > > > editor (as Jonathan is editor) to submit the next=20 > version of this=20 > > > > document as draft-ietf-sip-ua-loose-route-00. > > > >=20 > > > > Regards > > > >=20 > > > > Keith > > > >=20 > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > > > To: IETF SIP List > > > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards > > compatibility > > > > >=20 > > > > > I've recently revised my draft on UA loose routing. You can > > > > pick it up > > > > > here: > > > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > > > se-route-01.txt > > > > >=20 > > > > > This draft is meant to fulfill one of our charter items: > > > > > Feb 2008 Delivering request-URI and parameters=20 > > > > > to UAS via proxy to > > > > > IESG (PS) > > > > >=20 > > > > > As folks may recall, the GRUU spec used to have these > > > things called > > > > > grids, which allowed a UA to add its own parameters to the > > > > GRUU before > > > > > handing it out. Several GRUU revisions back, this function > > > > got yanked > > > > > because it was recognized that the problem was more general > > > > than GRUU, > > > > > and would be useful for AOR as well. > > > > >=20 > > > > > Two IETFs back I presented this draft briefly during a > > > SIP session.=20 > > > > > There was a lot of interest and people liked it > > architecturally, > > > > > however there were two open issues that needed to get > > > > resolved. This > > > > > mail is meant to start discussion on one of them - backwards=20 > > > > > compatibility. > > > > >=20 > > > > > THe mechanism basically changes the way proxies handle > > requests.=20 > > > > > Instead of rewriting the request URI for out-of-dialog > > requests, > > > > > they'll push a route header and leave the r-uri alone. This > > > > allows the > > > > > original R-URI and any parameters it contains to get > > > > delivered to the > > > > > UAS. > > > > >=20 > > > > > So, the main issue is, what kinds of backwards > > > > compatibility problems > > > > > will this cause. The draft provides a basic mechanism > > > whereby a UA > > > > > includes an option tag in the REGISTER, and the registrar > > > indicates > > > > > that it is using this mechanism or not. So we can > > negotiate this > > > > > between a UA and registrar easily. Now, the problem is with=20 > > > > > intermediate proxies. If there is an edge proxy between the > > > > UA and its > > > > > registrar, it will now see requests targeted to the UA, > > > > which contain > > > > > a Route header beyond itself, even though it thinks its the > > > > edge proxy > > > > > and the last point of contact before the UA. Technically, > > > > if this edge > > > > > proxy is compliant to rfc3261 it would work. However, the > > > > question is > > > > > whether proxies in the wild would properly work in this case. > > > > >=20 > > > > > If folks can comment based on their own products, or their=20 > > > > > experiences, on whether they think this would work, or > > > > concerns they > > > > > have, that would be great. THere are solutions that would > > > > allow us to > > > > > disable the mechanism when intermediate proxies don't > > > > support it, but > > > > > they are more complex and I'd rather avoid it. > > > > >=20 > > > > > THanks, > > > > > Jonathan R. > > > > > --=20 > > > > > Jonathan D. Rosenberg, Ph.D. 600=20 > Lanidex Plaza > > > > > Cisco Fellow Parsippany, NJ=20 > > > > > 07054-2711 > > > > > Cisco Systems > > > > > jdrosen@cisco.com FAX: =20 > > > (973) 952-5050 > > > > > http://www.jdrosen.net PHONE:=20 > > > (973) 952-5000 > > > > > http://www.cisco.com > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 06:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym9i-0004LC-9A; Thu, 14 Jun 2007 06:02:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hym9g-0004L6-R9 for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 06:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hym9g-0004Kv-HL for sip@ietf.org; Thu, 14 Jun 2007 06:02:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hym9f-0006ov-My for sip@ietf.org; Thu, 14 Jun 2007 06:02:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F412620107; Thu, 14 Jun 2007 12:02:14 +0200 (CEST) X-AuditID: c1b4fb3e-aee75bb0000007e1-ec-467112264ed6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CF057210C0; Thu, 14 Jun 2007 12:02:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 12:02:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 14 Jun 2007 12:02:13 +0200 Message-ID: <7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E677@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwAAAf5LgAAAo02A= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2 C41B98A6 A762007F5D019E677@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" X-OriginalArrivalTime: 14 Jun 2007 10:02:14.0413 (UTC) FILETIME=[1538DBD0:01C7AE6B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Yes, it affects all information, but in the case of DTMF we=20 >already have a mechanism for securing it, SRTP. So why=20 >attempt to standardise a new mechanism for transporting DTMF=20 >that introduces security issues that are already solved with=20 >the existing mechanism? Then, why did we do KPML? I am personally not saying people should use one solution instead of = another. I think the issue is that the market has seen a need for = out-of-band transport of DTMF tones, one reason being that all entities = using DTMF do not have access to the media. If you don't agree to that = requirement I think this is the wrong place to discuss it :) Regards, Christer > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 14 June 2007 10:41 > > To: Elwell, John > > Cc: SIP IETF > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > >=20 > > Hi John, > >=20 > > I hear what you are saying, but I don't see how this is specific to=20 > > DTMF and INFO. > >=20 > > Doesn't this affect all I kind of sensitive information=20 > that you want=20 > > to transport over SIP? > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > Sent: 14. kes=E4kuuta 2007 12:33 > > > To: Christer Holmberg (JO/LMF) > > > Cc: SIP IETF > > > Subject: RE: [Sip] INFO message belongs only to INVITE=20 > dialog usage? > > >=20 > > > Christer, > > >=20 > > > Slightly aside from the main direction of the discussion,=20 > but what=20 > > > about security? I send my audio using SRTP, and would=20 > expect DTMF to=20 > > > receive exactly the same protection. The signalling may=20 > or may not=20 > > > be end-to-end secured, depending on which of the current=20 > and future=20 > > > key management methods are used. Maybe SIPS has to be=20 > used, but we=20 > > > all know the limitations of that (e.g., if I receive an INVITE=20 > > > request to my SIPS URI, can I be sure all hops are=20 > secured?). I am=20 > > > sure the IETF would not want to endorse a mechanism that=20 > opens up a=20 > > > security hole that is not present with an existing mechanism for=20 > > > doing the same thing (RFC 2833). > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: 14 June 2007 10:20 > > > > To: Paul Kyzivat > > > > Cc: SIP IETF; Dean Willis > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > dialog usage? > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > >>I don't think an application will trigger INFOs in a > > > spray and pray > > > > >>matter. You will only send media server control messages > > > if you are > > > > >>communicating with a media server control application that=20 > > > > >>understands them. > > > > >=20 > > > > >How does my phone know it is communicating with a media > > > server that > > > > >understands INFO for conveying DTMF? The thing I call > > may indicate > > > > >support of INFO because it supports qsig tunneling. > > > >=20 > > > > It should also indicate support (using the Accept=20 > header) of the=20 > > > > content-type which is used to transport the media control > > messages. > > > > =20 > > > > >>>Before you send a DTMF/INFO, you really need to know that the > > > > recipient understands DTMF/INFO in general and the > > > > >>>specific encoding of DTMF in INFO that you're using (there > > > > have been > > > > >>>multiple encodings proposed). > > > > >>=20 > > > > >>Yes, and you know that if you receive an indication > > from the other > > > > party that he supports application/my-dtmf (or whatever > > > > >value is used). > > > > >>=20 > > > > >>And, if we would have standardized one encoding, maybe > > > > there wouldn't > > > > >>be multiple ones out there... > > > > >=20 > > > > >We currently have no way to say "I support mime-type foo > > > for use with > > > > >disposition bar and method baz", but in reality that is > > > going to be > > > > >the situation. I support sdp for disposition "session" in > > > the methods > > > > >that convey o/a. But I don't support sdp in MESSAGE or INFO. I=20 > > > > >support text/plain with > > > > content-type "render" > > > > in MESSAGE, but not for other > > > > >dispositions and other message types. > > > >=20 > > > > You don't have any way to say "I support mime-type SDP > > for use with > > > > disposition bar and method baz" either - that we specify > > elsewhere. > > > >=20 > > > > And, if we define a DTMF mime-type, we should of course > > also say in > > > > which SIP message it can be used etc. But, again, we should not=20 > > > > specify the applications that are going to use it. > > > >=20 > > > > Also, since INFO is not supposed to affect the SIP > > session, we can > > > > also put restrictions on which disposition values are to be > > > used etc. > > > >=20 > > > > So, of course there is some work to do, but that's not a > > reason to > > > > reject something. If everything was done and ready, there > > > would be no > > > > need for the SIP WG :) > > > >=20 > > > > >Getting an indication of support for application/my-dtmf > > is useful > > > > >*if* you know that the UA sending it to you always uses it > > > the same > > > > >ways you do. You can only know that if you control it, or > > > if all the > > > > >uses of that type are standardized. > > > >=20 > > > > It's up to the applications to make sure that the DTMFs are > > > sent and > > > > intepreted. If the receiving application has not asked for > > > DTMFs, and > > > > the sender still sends them, the receiver should simply > > > discard them. > > > > It's part of the application logic - not the SIP > > protocol. The SIP > > > > protocol defines information elements to indicate what > > > content types > > > > you support, what actions to take if the content type is > > > not supported > > > > etc. > > > > But, again: we don't specify what the applicatons are going > > > to do with > > > > information. > > > >=20 > > > > It's similar to when you use RFC2833 for sending DTMFs. The > > > only thing > > > > you do, as part of the offer/answer procedure, is agreeing > > > that both > > > > endpoints support RFC2833 - but you do not specify what the > > > endpoints > > > > are going to do with the tones, when they will be sent etc. > > > >=20 > > > > >>>And beyond just understanding your encoding of DTMF/INFO, > > > > you need to > > > >=20 > > > > >>>know that the recipient you are sending it to is=20 > likely to do=20 > > > > >>>something useful with that INFO, and that this "something > > > > useful" is > > > > >>>what you intend it to do when you send it. > > > > >> > > > > >>Yes, but you wouldn't send it unless you have a reason to > > > think the > > > > >>receiver is going to do something with it, e.g. if you > > have been > > > > >>asked to give your PIN code. > > > > >>=20 > > > > >>I don't understand why people think that applications > > would start > > > > >>sending all kind of INFOs "just for fun", without any > > > logic behind.=20 > > > > >>I have never seen that happen in real world deployments. I > > > > wouldn't > > > > >>start sending UPDATEs and/or re-INVITEs just for fun either,=20 > > > > >>eventhough there is nothing preventing me from doing it. > > > > >=20 > > > > >Lets go back to my phone. *It* doesn't know that I have > > > been asked to > > > > >give my PIN code, even though I do. All my phone knows is > > > that I have > > > > >pressed one of the buttons on the keypad. It may > > reasonably infer > > > > >that I want *something* to be done with them, and > > probably that I > > > > >want them sent to the other end in some way. It has no > > > idea *how* (or > > > > >*if*) the other end is prepared to receive them. > > > >=20 > > > > I think what you are talking about is how you will design > > your SIP > > > > phone. > > > >=20 > > > > For example, on my table phone, if I during a call want to > > > send DTMF > > > > tones I have to first press one button to "active" DTMF, > > > and then any > > > > button I sent is sent as DTMF. If I am asked to give my PIN > > > code, but > > > > do not active DTMF, nothing will happen when I press=20 > the buttons. > > > >=20 > > > > On my GSM phone, however, I don't need to active DTMF. If I > > > am asked > > > > to give my PIN code, I simply press buttons and they are > > > sent as DTMF > > > > tones. > > > >=20 > > > > >For instance, it may have indicated support for a mime > > > type that my > > > > >phone knows how to use to encode DTMF. But its possible it > > > was really > > > > >trying to say that it would support that type in a > > NOTIFY (sent or > > > > >received). > > > >=20 > > > > IF there are missing parts in the negotiation mechanism, > > we need to > > > > fix that. > > > >=20 > > > > Something like: > > > >=20 > > > > Accept: application/my-dtmf;method=3DINFO > > > >=20 > > > > OR, in the draft defining the content type, we specify > > that content > > > > type X can only be sent using this and that method. I > > > belive we do the > > > > same thing for SDP. > > > >=20 > > > > But, so far we haven't been interested in looking into > > > these issues.=20 > > > > We just say that using INFO is against the spirit of SIP, > > it causes > > > > all kind of problems etc etc. > > > >=20 > > > > My intention is not to "promote" the usage of INFO. My > > > issue is that > > > > the market has found and deployed an easy and effective way > > > of doing > > > > things using INFO, without breaking the protocol, and what > > > worries me > > > > is that instead of trying to help the market (e.g. by > > standardizing > > > > the content types, providing negotiation mechanism to achieve=20 > > > > interoperability), and in that way indirectly help them > > to come up > > > > with new SIP applications, we simply tell them that=20 > what they are=20 > > > > doing (and have been doing for > > > > years) is wrong, that they are breaking SIP, etc etc etc. > > > >=20 > > > > And, if we really wanted to restrict the usage of INFO, it > > > should have > > > > been done a long time ago - not years after the INFO RFC is > > > published > > > > and people have deployed usages of it. > > > >=20 > > > > Anyway, I guess we can go on with this discussion > > forever. Maybe we > > > > should find some time in Chicago and sit down and discuss this? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 06:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hymnu-00064a-Pi; Thu, 14 Jun 2007 06:43:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hymns-00062c-LU for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 06:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hymns-00062S-Bi for sip@ietf.org; Thu, 14 Jun 2007 06:43:48 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hymnr-0004KI-DH for sip@ietf.org; Thu, 14 Jun 2007 06:43:48 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BE4792097F; Thu, 14 Jun 2007 12:43:46 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-9f-46711be2e468 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9C75020887; Thu, 14 Jun 2007 12:43:46 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 12:43:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 14 Jun 2007 12:43:45 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054173E4@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAASVaVA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 14 Jun 2007 10:43:46.0162 (UTC) FILETIME=[E26B9520:01C7AE70] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 A small addition regarding the = does-your-phone-knows-that-it-shall-generate-DTMF-when-you-press-a-button= : wouldn't you have exactly the same problem no matter whether you use = INFO, RFC2833 or some other mechanism to transport the DTMF tones? Regards, Christer > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 14. kes=E4kuuta 2007 12:20 > To: Paul Kyzivat > Cc: SIP IETF; Dean Willis > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi,=20 >=20 > >>I don't think an application will trigger INFOs in a spray and pray=20 > >>matter. You will only send media server control messages if you are=20 > >>communicating with a media server control application that=20 > understands=20 > >>them. > >=20 > >How does my phone know it is communicating with a media server that=20 > >understands INFO for conveying DTMF? The thing I call may indicate=20 > >support of INFO because it supports qsig tunneling. >=20 > It should also indicate support (using the Accept header) of=20 > the content-type which is used to transport the media control=20 > messages. > =20 > >>>Before you send a DTMF/INFO, you really need to know that the > recipient understands DTMF/INFO in general and the=20 > >>>specific encoding of DTMF in INFO that you're using (there=20 > have been=20 > >>>multiple encodings proposed). > >>=20 > >>Yes, and you know that if you receive an indication from the other > party that he supports application/my-dtmf (or whatever=20 > >value is used). > >>=20 > >>And, if we would have standardized one encoding, maybe=20 > there wouldn't=20 > >>be multiple ones out there... > >=20 > >We currently have no way to say "I support mime-type foo for=20 > use with=20 > >disposition bar and method baz", but in reality that is=20 > going to be the=20 > >situation. I support sdp for disposition "session" in the=20 > methods that=20 > >convey o/a. But I don't support sdp in MESSAGE or INFO. I support=20 > >text/plain with content-type "render" > in MESSAGE, but not for other=20 > >dispositions and other message types. >=20 > You don't have any way to say "I support mime-type SDP for=20 > use with disposition bar and method baz" either - that we=20 > specify elsewhere. >=20 > And, if we define a DTMF mime-type, we should of course also=20 > say in which SIP message it can be used etc. But, again, we=20 > should not specify the applications that are going to use it. >=20 > Also, since INFO is not supposed to affect the SIP session,=20 > we can also put restrictions on which disposition values are=20 > to be used etc. >=20 > So, of course there is some work to do, but that's not a=20 > reason to reject something. If everything was done and ready,=20 > there would be no need for the SIP WG :) >=20 > >Getting an indication of support for application/my-dtmf is=20 > useful *if*=20 > >you know that the UA sending it to you always uses it the=20 > same ways you=20 > >do. You can only know that if you control it, or if all the uses of=20 > >that type are standardized. >=20 > It's up to the applications to make sure that the DTMFs are=20 > sent and intepreted. If the receiving application has not=20 > asked for DTMFs, and the sender still sends them, the=20 > receiver should simply discard them. > It's part of the application logic - not the SIP protocol.=20 > The SIP protocol defines information elements to indicate=20 > what content types you support, what actions to take if the=20 > content type is not supported etc. > But, again: we don't specify what the applicatons are going=20 > to do with information. >=20 > It's similar to when you use RFC2833 for sending DTMFs. The=20 > only thing you do, as part of the offer/answer procedure, is=20 > agreeing that both endpoints support RFC2833 - but you do not=20 > specify what the endpoints are going to do with the tones,=20 > when they will be sent etc. >=20 > >>>And beyond just understanding your encoding of DTMF/INFO,=20 > you need to >=20 > >>>know that the recipient you are sending it to is likely to do=20 > >>>something useful with that INFO, and that this "something=20 > useful" is=20 > >>>what you intend it to do when you send it. > >> > >>Yes, but you wouldn't send it unless you have a reason to think the=20 > >>receiver is going to do something with it, e.g. if you have=20 > been asked=20 > >>to give your PIN code. > >>=20 > >>I don't understand why people think that applications would start=20 > >>sending all kind of INFOs "just for fun", without any logic=20 > behind. I=20 > >>have never seen that happen in real world deployments. I > wouldn't=20 > >>start sending UPDATEs and/or re-INVITEs just for fun either,=20 > >>eventhough there is nothing preventing me from doing it. > >=20 > >Lets go back to my phone. *It* doesn't know that I have been=20 > asked to=20 > >give my PIN code, even though I do. All my phone knows is=20 > that I have=20 > >pressed one of the buttons on the keypad. It may reasonably=20 > infer that=20 > >I want *something* to be done with them, and probably that I=20 > want them=20 > >sent to the other end in some way. It has no idea *how* (or=20 > *if*) the=20 > >other end is prepared to receive them. >=20 > I think what you are talking about is how you will design=20 > your SIP phone. >=20 > For example, on my table phone, if I during a call want to=20 > send DTMF tones I have to first press one button to "active"=20 > DTMF, and then any button I sent is sent as DTMF. If I am=20 > asked to give my PIN code, but do not active DTMF, nothing=20 > will happen when I press the buttons. >=20 > On my GSM phone, however, I don't need to active DTMF. If I=20 > am asked to give my PIN code, I simply press buttons and they=20 > are sent as DTMF tones. >=20 > >For instance, it may have indicated support for a mime type that my=20 > >phone knows how to use to encode DTMF. But its possible it=20 > was really=20 > >trying to say that it would support that type in a NOTIFY (sent or=20 > >received). >=20 > IF there are missing parts in the negotiation mechanism, we=20 > need to fix that. >=20 > Something like: >=20 > Accept: application/my-dtmf;method=3DINFO >=20 > OR, in the draft defining the content type, we specify that=20 > content type X can only be sent using this and that method. I=20 > belive we do the same thing for SDP. >=20 > But, so far we haven't been interested in looking into these=20 > issues. We just say that using INFO is against the spirit of=20 > SIP, it causes all kind of problems etc etc. >=20 > My intention is not to "promote" the usage of INFO. My issue=20 > is that the market has found and deployed an easy and=20 > effective way of doing things using INFO, without breaking=20 > the protocol, and what worries me is that instead of trying=20 > to help the market (e.g. by standardizing the content types,=20 > providing negotiation mechanism to achieve interoperability),=20 > and in that way indirectly help them to come up with new SIP=20 > applications, we simply tell them that what they are doing=20 > (and have been doing for > years) is wrong, that they are breaking SIP, etc etc etc. >=20 > And, if we really wanted to restrict the usage of INFO, it=20 > should have been done a long time ago - not years after the=20 > INFO RFC is published and people have deployed usages of it. >=20 > Anyway, I guess we can go on with this discussion forever.=20 > Maybe we should find some time in Chicago and sit down and=20 > discuss this? >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 07:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn6A-0003Sn-I6; Thu, 14 Jun 2007 07:02:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyn68-0003SC-Oo for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 07:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn68-0003S4-Ez for sip@ietf.org; Thu, 14 Jun 2007 07:02:40 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyn66-00008Q-ER for sip@ietf.org; Thu, 14 Jun 2007 07:02:40 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E8000208FD; Thu, 14 Jun 2007 13:02:37 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-22-4671204dad60 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C162B20951; Thu, 14 Jun 2007 13:02:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:02:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 14 Jun 2007 13:02:36 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing thread-index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQAAAiGYQAABcmGAAAgiTMA== References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "DRAGE, Keith (Keith)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 14 Jun 2007 11:02:37.0396 (UTC) FILETIME=[84B03140:01C7AE73] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >It is entirely appropriate at this stage to put forward=20 >alternatives. It is even more appropriate to do it now rather=20 >than in 6 months time. >=20 >However please do not expect the editor to elaborate them. If=20 >the WG has ideas, send text, either by individual author=20 >drafts, or by the mailing list.=20 Regarding the P-Called-Party header, there already IS an RFC describing = the header, and what it is used for. So, IF it already solves the = problem (RFC3455 does say that the header is used to convey the AOR to = the UAS), why would we need a separate draft? The only additional = information that a draft could contain are the use-cases where receiving = the AOR is important - but those use-cases are solution independent and = already described in Jonathan's draft. Of course, if we want to define a NEW header, or a NEW URI parameter, = that may be done in a separate draft. But, no matter how we do it, I think the author should at least indicate = whether he has already thought about the alternatives that have been = presented, and why he thinks that they don't work. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, June 14, 2007 10:51 AM > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing > >=20 > >=20 > > Hi Keith, > >=20 > > The text you sent says: > >=20 > > "Consensus noted that we do need some sort of solution for=20 > the general=20 > > problem of delivery of URI parameters across contact-routing=20 > > operations." > >=20 > > I have no problems with that.=20 > >=20 > > I also have no problem with using Jonathan's draft as base line,=20 > > because the draft discusses the problem in a good way. > >=20 > > But, still: as the text says, the agreement was to come up=20 > with SOME=20 > > SORT OF SOLUTION, which to me does not mean that we have agreed to=20 > > adopt the specific solution in Jonathan's draft. We should also be=20 > > "allowed" to discuss alternative solutions, whether they=20 > are based on=20 > > P-Called-Party, some other header, some URI parameter, or=20 > whatever...=20 > > Maybe those alternative solutions do not work, and then we should=20 > > describe that (as Jonathan has done for the To header- and History=20 > > header alternatives). > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: 14. kes=E4kuuta 2007 12:40 > > > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] UA Loose Routing > > >=20 > > > You appear to be questioning whether the solution was=20 > adopted. The=20 > > > minutes state: > > >=20 > > >=20 > ------------------------------------------------------------------- > > > Topic: GRUU and Supporting Drafts =20 > > > Led by Jonathan Rosenberg > > > Slides included in proceedings > > > Read: draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > > >=20 > > > Change since last version reviewed. > > >=20 > > > Issue: GRUU subtype names. The room demonstrated a slight > > preference > > > for the names used in -11 over known alternatives, but=20 > nobody seems=20 > > > particularly enamored with these names and the floor > > remains open to > > > suggestions. > > >=20 > > > Discussion on ua-loose-route draft deferred to next session. > > >=20 > > >=20 > > > Session 2: Friday 0900-1130 Grand Ballroom C > > >=20 > > >=20 > > > Topic: UA-loose-route, continued from previous session. > > >=20 > > > Consensus noted that we do need some sort of solution for > > the general > > > problem of delivery of URI parameters across contact-routing=20 > > > operations. > > >=20 > > > Issue: Concerns raised about backward compatibility. Noted that=20 > > > compliant P-CSCF should be OK. Suggested that we have a > > design team > > > revisit call-flows and analyze for backward compatibility issues. > > >=20 > > > Issue: Does GRUU normatively depend on this work? Resolved:=20 > > > GRUU does not reference this document. However, some > > participants feel > > > it should, as the benefit of GRUU cannot be fully=20 > recognized in the=20 > > > absence of this specification. The chairs asked for a=20 > hum, and the=20 > > > consensus of the room is that GRUU and ua-loose-route can proceed=20 > > > independently. > > >=20 > > > Question: Adopt this draft as baseline text for a WG=20 > effort, should=20 > > > the ADs approve the milestone? Consensus to adopt noted by chairs. > > > To-do: Chairs to work with AD to set new milestone. > > >=20 > >=20 > ---------------------------------------------------------------------- > > >=20 > > > The minutes quite clearly say "Adopt this draft as baseline > > text for a > > > WG effort" and given that the charter item now exists, then > > I believe > > > that we are entitled to call for the editor (Jonathan) to > > submit the > > > current text as draft-ietf-sip-ua-loose-route. > > >=20 > > > I agree the file name says loose-route, but I don'y think=20 > we should=20 > > > change that. After all, we lose that filename when it gets > > published > > > as an RFC anyway. > > >=20 > > > The charter item states > > >=20 > > > Dec 2007 Delivering request-URI and parameters to UAS via=20 > > > proxy to WGLC =20 > > > Feb 2008 Delivering request-URI and parameters to UAS via=20 > > > proxy to IESG (PS) =20 > > >=20 > > > I assume that you are OK with this. > > >=20 > > > What I would suggest is that you address specific comments to the=20 > > > title of the deliverable: > > >=20 > > > Applying Loose Routing to Session Initiation Protocol > > > (SIP) User Agents (UA) > > >=20 > > > And to the abstract: > > >=20 > > > Abstract > > >=20 > > > A key part of the behavior of the Session Initiation > > Protocol (SIP) > > > is that SIP proxies rewrite the Request-URI as a request moves > > > throughout the network. Over the years, experience has > > shown this > > > to > > > be problematic. It makes it difficult to use Request URI for=20 > > > service > > > invocation, complicates emergency services, makes it > > more complex > > > to > > > support aliases, and so on. Architecturally, it confounds the > > > concepts of address and route. This document proposes=20 > to change=20 > > > this > > > through a new mechanism called UA loose routing. > > >=20 > > > As you think appropriate to your concerns. > > >=20 > > > Alternatively, if you (or indeed any other SIP WG member)=20 > do have a=20 > > > completely different solution, then there is still time=20 > to post an=20 > > > individual draft or post a skeleton of a mechanism to the list. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: Wednesday, June 13, 2007 8:52 PM > > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > > Subject: RE: [Sip] UA Loose Routing > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > We can call it loose route if we want, but I think the > > > initial focus > > > > should be the problem we are going to solve (I don't think > > > we agreed > > > > on a specific solution at #67), and we should look into > > alternative > > > > solutions (the draft does that in some extent, but=20 > other possible=20 > > > > alternatives have also been mentioned). > > > >=20 > > > > Or, do you prefer to have separate drafts describing=20 > alternative=20 > > > > solutions for the problem? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > Sent: 13. kes=E4kuuta 2007 22:25 > > > > > To: Jonathan Rosenberg; IETF SIP List > > > > > Subject: RE: [Sip] UA Loose Routing > > > > >=20 > > > > > (As WG chair) > > > > >=20 > > > > > As well as agreeing to charter the item, we actually agreed > > > > at IETF#67 > > > > > that this draft was a suitable candidate to fulfil that > > > > charter item. > > > > >=20 > > > > > Therefore unless issues are raised with this, I would > > request the > > > > > editor (as Jonathan is editor) to submit the next > > version of this > > > > > document as draft-ietf-sip-ua-loose-route-00. > > > > >=20 > > > > > Regards > > > > >=20 > > > > > Keith > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > > > > To: IETF SIP List > > > > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards > > > compatibility > > > > > >=20 > > > > > > I've recently revised my draft on UA loose routing. You can > > > > > pick it up > > > > > > here: > > > > > >=20 > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > > > > se-route-01.txt > > > > > >=20 > > > > > > This draft is meant to fulfill one of our charter items: > > > > > > Feb 2008 Delivering request-URI and parameters=20 > > > > > > to UAS via proxy to > > > > > > IESG (PS) > > > > > >=20 > > > > > > As folks may recall, the GRUU spec used to have these > > > > things called > > > > > > grids, which allowed a UA to add its own parameters to the > > > > > GRUU before > > > > > > handing it out. Several GRUU revisions back, this function > > > > > got yanked > > > > > > because it was recognized that the problem was more general > > > > > than GRUU, > > > > > > and would be useful for AOR as well. > > > > > >=20 > > > > > > Two IETFs back I presented this draft briefly during a > > > > SIP session.=20 > > > > > > There was a lot of interest and people liked it > > > architecturally, > > > > > > however there were two open issues that needed to get > > > > > resolved. This > > > > > > mail is meant to start discussion on one of them -=20 > backwards=20 > > > > > > compatibility. > > > > > >=20 > > > > > > THe mechanism basically changes the way proxies handle > > > requests.=20 > > > > > > Instead of rewriting the request URI for out-of-dialog > > > requests, > > > > > > they'll push a route header and leave the r-uri alone. This > > > > > allows the > > > > > > original R-URI and any parameters it contains to get > > > > > delivered to the > > > > > > UAS. > > > > > >=20 > > > > > > So, the main issue is, what kinds of backwards > > > > > compatibility problems > > > > > > will this cause. The draft provides a basic mechanism > > > > whereby a UA > > > > > > includes an option tag in the REGISTER, and the registrar > > > > indicates > > > > > > that it is using this mechanism or not. So we can > > > negotiate this > > > > > > between a UA and registrar easily. Now, the problem is with=20 > > > > > > intermediate proxies. If there is an edge proxy between the > > > > > UA and its > > > > > > registrar, it will now see requests targeted to the UA, > > > > > which contain > > > > > > a Route header beyond itself, even though it thinks its the > > > > > edge proxy > > > > > > and the last point of contact before the UA. Technically, > > > > > if this edge > > > > > > proxy is compliant to rfc3261 it would work. However, the > > > > > question is > > > > > > whether proxies in the wild would properly work in=20 > this case. > > > > > >=20 > > > > > > If folks can comment based on their own products, or their=20 > > > > > > experiences, on whether they think this would work, or > > > > > concerns they > > > > > > have, that would be great. THere are solutions that would > > > > > allow us to > > > > > > disable the mechanism when intermediate proxies don't > > > > > support it, but > > > > > > they are more complex and I'd rather avoid it. > > > > > >=20 > > > > > > THanks, > > > > > > Jonathan R. > > > > > > --=20 > > > > > > Jonathan D. Rosenberg, Ph.D. 600=20 > > Lanidex Plaza > > > > > > Cisco Fellow =20 > Parsippany, NJ=20 > > > > > > 07054-2711 > > > > > > Cisco Systems > > > > > > jdrosen@cisco.com FAX: =20 > > > > (973) 952-5050 > > > > > > http://www.jdrosen.net PHONE:=20 > > > > (973) 952-5000 > > > > > > http://www.cisco.com > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 08:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyoKj-0005DP-1j; Thu, 14 Jun 2007 08:21:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyoKi-0005DK-EH for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyoKi-0005DC-4W for sip@ietf.org; Thu, 14 Jun 2007 08:21:48 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyoKg-0007zD-8f for sip@ietf.org; Thu, 14 Jun 2007 08:21:48 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJM00830KZXO7@siemenscomms.co.uk> for sip@ietf.org; Thu, 14 Jun 2007 13:21:33 +0100 (BST) Date: Thu, 14 Jun 2007 13:21:44 +0100 From: "Elwell, John" Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? In-reply-to: A <7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se> To: "Christer Holmberg (JO/LMF)" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwAAAf5LgAAAo02AABJQ4IA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> <"0D5F89FAC29E2 C41B98 A6 A762007F5 D019E677"@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, In-line. John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 14 June 2007 11:02 > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi,=20 >=20 > >Yes, it affects all information, but in the case of DTMF we=20 > >already have a mechanism for securing it, SRTP. So why=20 > >attempt to standardise a new mechanism for transporting DTMF=20 > >that introduces security issues that are already solved with=20 > >the existing mechanism? >=20 > Then, why did we do KPML? [JRE] KPML addresses a different problem space, i.e., an application = server that doesn't necessarily have any audio and/or DTMF capability. >=20 > I am personally not saying people should use one solution=20 > instead of another. I think the issue is that the market has=20 > seen a need for out-of-band transport of DTMF tones, one=20 > reason being that all entities using DTMF do not have access=20 > to the media.=20 [JRE] KPML addresses this space. Because it establishes a dialog for = the purpose, KPML can ensure that SIPS is used, even if SIPS is not used = for the INVITE-initiated dialog. Why do we need a different solution? > If you don't agree to that requirement I think=20 > this is the wrong place to discuss it :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: 14 June 2007 10:41 > > > To: Elwell, John > > > Cc: SIP IETF > > > Subject: RE: [Sip] INFO message belongs only to INVITE=20 > dialog usage? > > >=20 > > >=20 > > > Hi John, > > >=20 > > > I hear what you are saying, but I don't see how this is=20 > specific to=20 > > > DTMF and INFO. > > >=20 > > > Doesn't this affect all I kind of sensitive information=20 > > that you want=20 > > > to transport over SIP? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > Sent: 14. kes=E4kuuta 2007 12:33 > > > > To: Christer Holmberg (JO/LMF) > > > > Cc: SIP IETF > > > > Subject: RE: [Sip] INFO message belongs only to INVITE=20 > > dialog usage? > > > >=20 > > > > Christer, > > > >=20 > > > > Slightly aside from the main direction of the discussion,=20 > > but what=20 > > > > about security? I send my audio using SRTP, and would=20 > > expect DTMF to=20 > > > > receive exactly the same protection. The signalling may=20 > > or may not=20 > > > > be end-to-end secured, depending on which of the current=20 > > and future=20 > > > > key management methods are used. Maybe SIPS has to be=20 > > used, but we=20 > > > > all know the limitations of that (e.g., if I receive an INVITE=20 > > > > request to my SIPS URI, can I be sure all hops are=20 > > secured?). I am=20 > > > > sure the IETF would not want to endorse a mechanism that=20 > > opens up a=20 > > > > security hole that is not present with an existing=20 > mechanism for=20 > > > > doing the same thing (RFC 2833). > > > >=20 > > > > John > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF) > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 14 June 2007 10:20 > > > > > To: Paul Kyzivat > > > > > Cc: SIP IETF; Dean Willis > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > dialog usage? > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > >>I don't think an application will trigger INFOs in a > > > > spray and pray > > > > > >>matter. You will only send media server control messages > > > > if you are > > > > > >>communicating with a media server control application that=20 > > > > > >>understands them. > > > > > >=20 > > > > > >How does my phone know it is communicating with a media > > > > server that > > > > > >understands INFO for conveying DTMF? The thing I call > > > may indicate > > > > > >support of INFO because it supports qsig tunneling. > > > > >=20 > > > > > It should also indicate support (using the Accept=20 > > header) of the=20 > > > > > content-type which is used to transport the media control > > > messages. > > > > > =20 > > > > > >>>Before you send a DTMF/INFO, you really need to=20 > know that the > > > > > recipient understands DTMF/INFO in general and the > > > > > >>>specific encoding of DTMF in INFO that you're using (there > > > > > have been > > > > > >>>multiple encodings proposed). > > > > > >>=20 > > > > > >>Yes, and you know that if you receive an indication > > > from the other > > > > > party that he supports application/my-dtmf (or whatever > > > > > >value is used). > > > > > >>=20 > > > > > >>And, if we would have standardized one encoding, maybe > > > > > there wouldn't > > > > > >>be multiple ones out there... > > > > > >=20 > > > > > >We currently have no way to say "I support mime-type foo > > > > for use with > > > > > >disposition bar and method baz", but in reality that is > > > > going to be > > > > > >the situation. I support sdp for disposition "session" in > > > > the methods > > > > > >that convey o/a. But I don't support sdp in MESSAGE=20 > or INFO. I=20 > > > > > >support text/plain with > > > > > content-type "render" > > > > > in MESSAGE, but not for other > > > > > >dispositions and other message types. > > > > >=20 > > > > > You don't have any way to say "I support mime-type SDP > > > for use with > > > > > disposition bar and method baz" either - that we specify > > > elsewhere. > > > > >=20 > > > > > And, if we define a DTMF mime-type, we should of course > > > also say in > > > > > which SIP message it can be used etc. But, again, we=20 > should not=20 > > > > > specify the applications that are going to use it. > > > > >=20 > > > > > Also, since INFO is not supposed to affect the SIP > > > session, we can > > > > > also put restrictions on which disposition values are to be > > > > used etc. > > > > >=20 > > > > > So, of course there is some work to do, but that's not a > > > reason to > > > > > reject something. If everything was done and ready, there > > > > would be no > > > > > need for the SIP WG :) > > > > >=20 > > > > > >Getting an indication of support for application/my-dtmf > > > is useful > > > > > >*if* you know that the UA sending it to you always uses it > > > > the same > > > > > >ways you do. You can only know that if you control it, or > > > > if all the > > > > > >uses of that type are standardized. > > > > >=20 > > > > > It's up to the applications to make sure that the DTMFs are > > > > sent and > > > > > intepreted. If the receiving application has not asked for > > > > DTMFs, and > > > > > the sender still sends them, the receiver should simply > > > > discard them. > > > > > It's part of the application logic - not the SIP > > > protocol. The SIP > > > > > protocol defines information elements to indicate what > > > > content types > > > > > you support, what actions to take if the content type is > > > > not supported > > > > > etc. > > > > > But, again: we don't specify what the applicatons are going > > > > to do with > > > > > information. > > > > >=20 > > > > > It's similar to when you use RFC2833 for sending DTMFs. The > > > > only thing > > > > > you do, as part of the offer/answer procedure, is agreeing > > > > that both > > > > > endpoints support RFC2833 - but you do not specify what the > > > > endpoints > > > > > are going to do with the tones, when they will be sent etc. > > > > >=20 > > > > > >>>And beyond just understanding your encoding of DTMF/INFO, > > > > > you need to > > > > >=20 > > > > > >>>know that the recipient you are sending it to is=20 > > likely to do=20 > > > > > >>>something useful with that INFO, and that this "something > > > > > useful" is > > > > > >>>what you intend it to do when you send it. > > > > > >> > > > > > >>Yes, but you wouldn't send it unless you have a reason to > > > > think the > > > > > >>receiver is going to do something with it, e.g. if you > > > have been > > > > > >>asked to give your PIN code. > > > > > >>=20 > > > > > >>I don't understand why people think that applications > > > would start > > > > > >>sending all kind of INFOs "just for fun", without any > > > > logic behind.=20 > > > > > >>I have never seen that happen in real world deployments. I > > > > > wouldn't > > > > > >>start sending UPDATEs and/or re-INVITEs just for=20 > fun either,=20 > > > > > >>eventhough there is nothing preventing me from doing it. > > > > > >=20 > > > > > >Lets go back to my phone. *It* doesn't know that I have > > > > been asked to > > > > > >give my PIN code, even though I do. All my phone knows is > > > > that I have > > > > > >pressed one of the buttons on the keypad. It may > > > reasonably infer > > > > > >that I want *something* to be done with them, and > > > probably that I > > > > > >want them sent to the other end in some way. It has no > > > > idea *how* (or > > > > > >*if*) the other end is prepared to receive them. > > > > >=20 > > > > > I think what you are talking about is how you will design > > > your SIP > > > > > phone. > > > > >=20 > > > > > For example, on my table phone, if I during a call want to > > > > send DTMF > > > > > tones I have to first press one button to "active" DTMF, > > > > and then any > > > > > button I sent is sent as DTMF. If I am asked to give my PIN > > > > code, but > > > > > do not active DTMF, nothing will happen when I press=20 > > the buttons. > > > > >=20 > > > > > On my GSM phone, however, I don't need to active DTMF. If I > > > > am asked > > > > > to give my PIN code, I simply press buttons and they are > > > > sent as DTMF > > > > > tones. > > > > >=20 > > > > > >For instance, it may have indicated support for a mime > > > > type that my > > > > > >phone knows how to use to encode DTMF. But its possible it > > > > was really > > > > > >trying to say that it would support that type in a > > > NOTIFY (sent or > > > > > >received). > > > > >=20 > > > > > IF there are missing parts in the negotiation mechanism, > > > we need to > > > > > fix that. > > > > >=20 > > > > > Something like: > > > > >=20 > > > > > Accept: application/my-dtmf;method=3DINFO > > > > >=20 > > > > > OR, in the draft defining the content type, we specify > > > that content > > > > > type X can only be sent using this and that method. I > > > > belive we do the > > > > > same thing for SDP. > > > > >=20 > > > > > But, so far we haven't been interested in looking into > > > > these issues.=20 > > > > > We just say that using INFO is against the spirit of SIP, > > > it causes > > > > > all kind of problems etc etc. > > > > >=20 > > > > > My intention is not to "promote" the usage of INFO. My > > > > issue is that > > > > > the market has found and deployed an easy and effective way > > > > of doing > > > > > things using INFO, without breaking the protocol, and what > > > > worries me > > > > > is that instead of trying to help the market (e.g. by > > > standardizing > > > > > the content types, providing negotiation mechanism to achieve=20 > > > > > interoperability), and in that way indirectly help them > > > to come up > > > > > with new SIP applications, we simply tell them that=20 > > what they are=20 > > > > > doing (and have been doing for > > > > > years) is wrong, that they are breaking SIP, etc etc etc. > > > > >=20 > > > > > And, if we really wanted to restrict the usage of INFO, it > > > > should have > > > > > been done a long time ago - not years after the INFO RFC is > > > > published > > > > > and people have deployed usages of it. > > > > >=20 > > > > > Anyway, I guess we can go on with this discussion > > > forever. Maybe we > > > > > should find some time in Chicago and sit down and=20 > discuss this? > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > > sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use=20 > > > > > sipping@ietf.org for new developments on the=20 > application of sip > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 08:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyoaf-0001kC-R3; Thu, 14 Jun 2007 08:38:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyoae-0001jy-DU for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyoae-0001jq-3r for sip@ietf.org; Thu, 14 Jun 2007 08:38:16 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyoac-0004Vq-Vk for sip@ietf.org; Thu, 14 Jun 2007 08:38:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6B0C32137D; Thu, 14 Jun 2007 14:38:14 +0200 (CEST) X-AuditID: c1b4fb3e-ae674bb0000007e1-a0-467136b6ee6c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 519E920164; Thu, 14 Jun 2007 14:38:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:38:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Thu, 14 Jun 2007 14:38:02 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwAAAf5LgAAAo02AABJQ4IAAAwhYA References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> A <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se> <"0D5F89FAC29E 2 C41B98 A6 A762007F 5 D019E677"@GBNTHT12009MSX.gb002.siemens.net> A <7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" X-OriginalArrivalTime: 14 Jun 2007 12:38:13.0666 (UTC) FILETIME=[DFC58820:01C7AE80] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John=20 >>I am personally not saying people should use one solution instead of=20 >>another. I think the issue is that the market has seen a need for=20 >>out-of-band transport of DTMF tones, one reason being that all=20 >>entities using DTMF do not have access to the media. >[JRE] KPML addresses this space. Because it establishes a=20 >dialog for the purpose, KPML can ensure that SIPS is used,=20 >even if SIPS is not used for the INVITE-initiated dialog. >Why do we need a different solution? The problem is that the INFO solution was implemented BEFORE KPML was = finalized. I also believe that many people think it's easier do handle it in a = single dialog, without having to establish and associate two separate = ones. But, that's just my guessing (I have personally never had to make = the decisson which solution to implement based on technical arguments). Regards, Christer > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: 14 June 2007 10:41 > > > > To: Elwell, John > > > > Cc: SIP IETF > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > dialog usage? > > > >=20 > > > >=20 > > > > Hi John, > > > >=20 > > > > I hear what you are saying, but I don't see how this is > > specific to > > > > DTMF and INFO. > > > >=20 > > > > Doesn't this affect all I kind of sensitive information > > > that you want > > > > to transport over SIP? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > Sent: 14. kes=E4kuuta 2007 12:33 > > > > > To: Christer Holmberg (JO/LMF) > > > > > Cc: SIP IETF > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > dialog usage? > > > > >=20 > > > > > Christer, > > > > >=20 > > > > > Slightly aside from the main direction of the discussion, > > > but what > > > > > about security? I send my audio using SRTP, and would > > > expect DTMF to > > > > > receive exactly the same protection. The signalling may > > > or may not > > > > > be end-to-end secured, depending on which of the current > > > and future > > > > > key management methods are used. Maybe SIPS has to be > > > used, but we > > > > > all know the limitations of that (e.g., if I receive=20 > an INVITE=20 > > > > > request to my SIPS URI, can I be sure all hops are > > > secured?). I am > > > > > sure the IETF would not want to endorse a mechanism that > > > opens up a > > > > > security hole that is not present with an existing > > mechanism for > > > > > doing the same thing (RFC 2833). > > > > >=20 > > > > > John > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg (JO/LMF)=20 > > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: 14 June 2007 10:20 > > > > > > To: Paul Kyzivat > > > > > > Cc: SIP IETF; Dean Willis > > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > > dialog usage? > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > >>I don't think an application will trigger INFOs in a > > > > > spray and pray > > > > > > >>matter. You will only send media server control messages > > > > > if you are > > > > > > >>communicating with a media server control=20 > application that=20 > > > > > > >>understands them. > > > > > > >=20 > > > > > > >How does my phone know it is communicating with a media > > > > > server that > > > > > > >understands INFO for conveying DTMF? The thing I call > > > > may indicate > > > > > > >support of INFO because it supports qsig tunneling. > > > > > >=20 > > > > > > It should also indicate support (using the Accept > > > header) of the > > > > > > content-type which is used to transport the media control > > > > messages. > > > > > > =20 > > > > > > >>>Before you send a DTMF/INFO, you really need to > > know that the > > > > > > recipient understands DTMF/INFO in general and the > > > > > > >>>specific encoding of DTMF in INFO that you're=20 > using (there > > > > > > have been > > > > > > >>>multiple encodings proposed). > > > > > > >>=20 > > > > > > >>Yes, and you know that if you receive an indication > > > > from the other > > > > > > party that he supports application/my-dtmf (or whatever > > > > > > >value is used). > > > > > > >>=20 > > > > > > >>And, if we would have standardized one encoding, maybe > > > > > > there wouldn't > > > > > > >>be multiple ones out there... > > > > > > >=20 > > > > > > >We currently have no way to say "I support mime-type foo > > > > > for use with > > > > > > >disposition bar and method baz", but in reality that is > > > > > going to be > > > > > > >the situation. I support sdp for disposition "session" in > > > > > the methods > > > > > > >that convey o/a. But I don't support sdp in MESSAGE > > or INFO. I > > > > > > >support text/plain with > > > > > > content-type "render" > > > > > > in MESSAGE, but not for other > > > > > > >dispositions and other message types. > > > > > >=20 > > > > > > You don't have any way to say "I support mime-type SDP > > > > for use with > > > > > > disposition bar and method baz" either - that we specify > > > > elsewhere. > > > > > >=20 > > > > > > And, if we define a DTMF mime-type, we should of course > > > > also say in > > > > > > which SIP message it can be used etc. But, again, we > > should not > > > > > > specify the applications that are going to use it. > > > > > >=20 > > > > > > Also, since INFO is not supposed to affect the SIP > > > > session, we can > > > > > > also put restrictions on which disposition values are to be > > > > > used etc. > > > > > >=20 > > > > > > So, of course there is some work to do, but that's not a > > > > reason to > > > > > > reject something. If everything was done and ready, there > > > > > would be no > > > > > > need for the SIP WG :) > > > > > >=20 > > > > > > >Getting an indication of support for application/my-dtmf > > > > is useful > > > > > > >*if* you know that the UA sending it to you always uses it > > > > > the same > > > > > > >ways you do. You can only know that if you control it, or > > > > > if all the > > > > > > >uses of that type are standardized. > > > > > >=20 > > > > > > It's up to the applications to make sure that the DTMFs are > > > > > sent and > > > > > > intepreted. If the receiving application has not asked for > > > > > DTMFs, and > > > > > > the sender still sends them, the receiver should simply > > > > > discard them. > > > > > > It's part of the application logic - not the SIP > > > > protocol. The SIP > > > > > > protocol defines information elements to indicate what > > > > > content types > > > > > > you support, what actions to take if the content type is > > > > > not supported > > > > > > etc. > > > > > > But, again: we don't specify what the applicatons are going > > > > > to do with > > > > > > information. > > > > > >=20 > > > > > > It's similar to when you use RFC2833 for sending DTMFs. The > > > > > only thing > > > > > > you do, as part of the offer/answer procedure, is agreeing > > > > > that both > > > > > > endpoints support RFC2833 - but you do not specify what the > > > > > endpoints > > > > > > are going to do with the tones, when they will be sent etc. > > > > > >=20 > > > > > > >>>And beyond just understanding your encoding of DTMF/INFO, > > > > > > you need to > > > > > >=20 > > > > > > >>>know that the recipient you are sending it to is > > > likely to do > > > > > > >>>something useful with that INFO, and that this "something > > > > > > useful" is > > > > > > >>>what you intend it to do when you send it. > > > > > > >> > > > > > > >>Yes, but you wouldn't send it unless you have a reason to > > > > > think the > > > > > > >>receiver is going to do something with it, e.g. if you > > > > have been > > > > > > >>asked to give your PIN code. > > > > > > >>=20 > > > > > > >>I don't understand why people think that applications > > > > would start > > > > > > >>sending all kind of INFOs "just for fun", without any > > > > > logic behind.=20 > > > > > > >>I have never seen that happen in real world deployments. I > > > > > > wouldn't > > > > > > >>start sending UPDATEs and/or re-INVITEs just for > > fun either, > > > > > > >>eventhough there is nothing preventing me from doing it. > > > > > > >=20 > > > > > > >Lets go back to my phone. *It* doesn't know that I have > > > > > been asked to > > > > > > >give my PIN code, even though I do. All my phone knows is > > > > > that I have > > > > > > >pressed one of the buttons on the keypad. It may > > > > reasonably infer > > > > > > >that I want *something* to be done with them, and > > > > probably that I > > > > > > >want them sent to the other end in some way. It has no > > > > > idea *how* (or > > > > > > >*if*) the other end is prepared to receive them. > > > > > >=20 > > > > > > I think what you are talking about is how you will design > > > > your SIP > > > > > > phone. > > > > > >=20 > > > > > > For example, on my table phone, if I during a call want to > > > > > send DTMF > > > > > > tones I have to first press one button to "active" DTMF, > > > > > and then any > > > > > > button I sent is sent as DTMF. If I am asked to give my PIN > > > > > code, but > > > > > > do not active DTMF, nothing will happen when I press > > > the buttons. > > > > > >=20 > > > > > > On my GSM phone, however, I don't need to active DTMF. If I > > > > > am asked > > > > > > to give my PIN code, I simply press buttons and they are > > > > > sent as DTMF > > > > > > tones. > > > > > >=20 > > > > > > >For instance, it may have indicated support for a mime > > > > > type that my > > > > > > >phone knows how to use to encode DTMF. But its possible it > > > > > was really > > > > > > >trying to say that it would support that type in a > > > > NOTIFY (sent or > > > > > > >received). > > > > > >=20 > > > > > > IF there are missing parts in the negotiation mechanism, > > > > we need to > > > > > > fix that. > > > > > >=20 > > > > > > Something like: > > > > > >=20 > > > > > > Accept: application/my-dtmf;method=3DINFO > > > > > >=20 > > > > > > OR, in the draft defining the content type, we specify > > > > that content > > > > > > type X can only be sent using this and that method. I > > > > > belive we do the > > > > > > same thing for SDP. > > > > > >=20 > > > > > > But, so far we haven't been interested in looking into > > > > > these issues.=20 > > > > > > We just say that using INFO is against the spirit of SIP, > > > > it causes > > > > > > all kind of problems etc etc. > > > > > >=20 > > > > > > My intention is not to "promote" the usage of INFO. My > > > > > issue is that > > > > > > the market has found and deployed an easy and effective way > > > > > of doing > > > > > > things using INFO, without breaking the protocol, and what > > > > > worries me > > > > > > is that instead of trying to help the market (e.g. by > > > > standardizing > > > > > > the content types, providing negotiation mechanism=20 > to achieve=20 > > > > > > interoperability), and in that way indirectly help them > > > > to come up > > > > > > with new SIP applications, we simply tell them that > > > what they are > > > > > > doing (and have been doing for > > > > > > years) is wrong, that they are breaking SIP, etc etc etc. > > > > > >=20 > > > > > > And, if we really wanted to restrict the usage of INFO, it > > > > > should have > > > > > > been done a long time ago - not years after the INFO RFC is > > > > > published > > > > > > and people have deployed usages of it. > > > > > >=20 > > > > > > Anyway, I guess we can go on with this discussion > > > > forever. Maybe we > > > > > > should find some time in Chicago and sit down and > > discuss this? > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Christer > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the > > application of sip > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 08:49:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyol7-0007y6-IY; Thu, 14 Jun 2007 08:49:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyol6-0007qb-DJ for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:49:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyol6-0007pM-2j for sip@ietf.org; Thu, 14 Jun 2007 08:49:04 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyol3-0007mI-SC for sip@ietf.org; Thu, 14 Jun 2007 08:49:04 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJM00F5HM8VO0@siemenscomms.co.uk> for sip@ietf.org; Thu, 14 Jun 2007 13:48:32 +0100 (BST) Date: Thu, 14 Jun 2007 13:48:40 +0100 From: "Elwell, John" Subject: RE: [Sip] UA Loose Routing In-reply-to: A <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> To: "Christer Holmberg (JO/LMF)" , "DRAGE, Keith (Keith)" , Jonathan Rosenberg , IETF SIP List Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E6C8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Sip] UA Loose Routing Thread-Index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQAAAiGYQAABcmGAAAgiTMAAEB2ww Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> A <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer, For clarification, does the P-Called-party header field URI get = overwritten when retargeting (as opposed to routing) occurs? If not, I = fear it suffers from the same problem as the To header field URI, as = described in Jonathan's draft. John=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: 14 June 2007 12:03 > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing >=20 >=20 > Hi,=20 >=20 > >It is entirely appropriate at this stage to put forward=20 > >alternatives. It is even more appropriate to do it now rather=20 > >than in 6 months time. > >=20 > >However please do not expect the editor to elaborate them. If=20 > >the WG has ideas, send text, either by individual author=20 > >drafts, or by the mailing list.=20 >=20 > Regarding the P-Called-Party header, there already IS an RFC=20 > describing the header, and what it is used for. So, IF it=20 > already solves the problem (RFC3455 does say that the header=20 > is used to convey the AOR to the UAS), why would we need a=20 > separate draft? The only additional information that a draft=20 > could contain are the use-cases where receiving the AOR is=20 > important - but those use-cases are solution independent and=20 > already described in Jonathan's draft. >=20 > Of course, if we want to define a NEW header, or a NEW URI=20 > parameter, that may be done in a separate draft. >=20 > But, no matter how we do it, I think the author should at=20 > least indicate whether he has already thought about the=20 > alternatives that have been presented, and why he thinks that=20 > they don't work. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Thursday, June 14, 2007 10:51 AM > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > Subject: RE: [Sip] UA Loose Routing > > >=20 > > >=20 > > > Hi Keith, > > >=20 > > > The text you sent says: > > >=20 > > > "Consensus noted that we do need some sort of solution for=20 > > the general=20 > > > problem of delivery of URI parameters across contact-routing=20 > > > operations." > > >=20 > > > I have no problems with that.=20 > > >=20 > > > I also have no problem with using Jonathan's draft as base line,=20 > > > because the draft discusses the problem in a good way. > > >=20 > > > But, still: as the text says, the agreement was to come up=20 > > with SOME=20 > > > SORT OF SOLUTION, which to me does not mean that we have=20 > agreed to=20 > > > adopt the specific solution in Jonathan's draft. We=20 > should also be=20 > > > "allowed" to discuss alternative solutions, whether they=20 > > are based on=20 > > > P-Called-Party, some other header, some URI parameter, or=20 > > whatever...=20 > > > Maybe those alternative solutions do not work, and then we should=20 > > > describe that (as Jonathan has done for the To header-=20 > and History=20 > > > header alternatives). > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > Sent: 14. kes=E4kuuta 2007 12:40 > > > > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg;=20 > IETF SIP List > > > > Subject: RE: [Sip] UA Loose Routing > > > >=20 > > > > You appear to be questioning whether the solution was=20 > > adopted. The=20 > > > > minutes state: > > > >=20 > > > >=20 > > ------------------------------------------------------------------- > > > > Topic: GRUU and Supporting Drafts =20 > > > > Led by Jonathan Rosenberg > > > > Slides included in proceedings > > > > Read:=20 > draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > > > >=20 > > > > Change since last version reviewed. > > > >=20 > > > > Issue: GRUU subtype names. The room demonstrated a slight > > > preference > > > > for the names used in -11 over known alternatives, but=20 > > nobody seems=20 > > > > particularly enamored with these names and the floor > > > remains open to > > > > suggestions. > > > >=20 > > > > Discussion on ua-loose-route draft deferred to next session. > > > >=20 > > > >=20 > > > > Session 2: Friday 0900-1130 Grand Ballroom C > > > >=20 > > > >=20 > > > > Topic: UA-loose-route, continued from previous session. > > > >=20 > > > > Consensus noted that we do need some sort of solution for > > > the general > > > > problem of delivery of URI parameters across contact-routing=20 > > > > operations. > > > >=20 > > > > Issue: Concerns raised about backward compatibility. Noted that=20 > > > > compliant P-CSCF should be OK. Suggested that we have a > > > design team > > > > revisit call-flows and analyze for backward=20 > compatibility issues. > > > >=20 > > > > Issue: Does GRUU normatively depend on this work? Resolved:=20 > > > > GRUU does not reference this document. However, some > > > participants feel > > > > it should, as the benefit of GRUU cannot be fully=20 > > recognized in the=20 > > > > absence of this specification. The chairs asked for a=20 > > hum, and the=20 > > > > consensus of the room is that GRUU and ua-loose-route=20 > can proceed=20 > > > > independently. > > > >=20 > > > > Question: Adopt this draft as baseline text for a WG=20 > > effort, should=20 > > > > the ADs approve the milestone? Consensus to adopt noted=20 > by chairs. > > > > To-do: Chairs to work with AD to set new milestone. > > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > >=20 > > > > The minutes quite clearly say "Adopt this draft as baseline > > > text for a > > > > WG effort" and given that the charter item now exists, then > > > I believe > > > > that we are entitled to call for the editor (Jonathan) to > > > submit the > > > > current text as draft-ietf-sip-ua-loose-route. > > > >=20 > > > > I agree the file name says loose-route, but I don'y think=20 > > we should=20 > > > > change that. After all, we lose that filename when it gets > > > published > > > > as an RFC anyway. > > > >=20 > > > > The charter item states > > > >=20 > > > > Dec 2007 Delivering request-URI and parameters to UAS via=20 > > > > proxy to WGLC =20 > > > > Feb 2008 Delivering request-URI and parameters to UAS via=20 > > > > proxy to IESG (PS) =20 > > > >=20 > > > > I assume that you are OK with this. > > > >=20 > > > > What I would suggest is that you address specific=20 > comments to the=20 > > > > title of the deliverable: > > > >=20 > > > > Applying Loose Routing to Session Initiation Protocol > > > > (SIP) User Agents (UA) > > > >=20 > > > > And to the abstract: > > > >=20 > > > > Abstract > > > >=20 > > > > A key part of the behavior of the Session Initiation > > > Protocol (SIP) > > > > is that SIP proxies rewrite the Request-URI as a=20 > request moves > > > > throughout the network. Over the years, experience has > > > shown this > > > > to > > > > be problematic. It makes it difficult to use=20 > Request URI for=20 > > > > service > > > > invocation, complicates emergency services, makes it > > > more complex > > > > to > > > > support aliases, and so on. Architecturally, it=20 > confounds the > > > > concepts of address and route. This document proposes=20 > > to change=20 > > > > this > > > > through a new mechanism called UA loose routing. > > > >=20 > > > > As you think appropriate to your concerns. > > > >=20 > > > > Alternatively, if you (or indeed any other SIP WG member)=20 > > do have a=20 > > > > completely different solution, then there is still time=20 > > to post an=20 > > > > individual draft or post a skeleton of a mechanism to the list. > > > >=20 > > > > Regards > > > >=20 > > > > Keith > > > >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF) > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Wednesday, June 13, 2007 8:52 PM > > > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > > > Subject: RE: [Sip] UA Loose Routing > > > > >=20 > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > We can call it loose route if we want, but I think the > > > > initial focus > > > > > should be the problem we are going to solve (I don't think > > > > we agreed > > > > > on a specific solution at #67), and we should look into > > > alternative > > > > > solutions (the draft does that in some extent, but=20 > > other possible=20 > > > > > alternatives have also been mentioned). > > > > >=20 > > > > > Or, do you prefer to have separate drafts describing=20 > > alternative=20 > > > > > solutions for the problem? > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Christer > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > > Sent: 13. kes=E4kuuta 2007 22:25 > > > > > > To: Jonathan Rosenberg; IETF SIP List > > > > > > Subject: RE: [Sip] UA Loose Routing > > > > > >=20 > > > > > > (As WG chair) > > > > > >=20 > > > > > > As well as agreeing to charter the item, we actually agreed > > > > > at IETF#67 > > > > > > that this draft was a suitable candidate to fulfil that > > > > > charter item. > > > > > >=20 > > > > > > Therefore unless issues are raised with this, I would > > > request the > > > > > > editor (as Jonathan is editor) to submit the next > > > version of this > > > > > > document as draft-ietf-sip-ua-loose-route-00. > > > > > >=20 > > > > > > Regards > > > > > >=20 > > > > > > Keith > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > > > > > To: IETF SIP List > > > > > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards > > > > compatibility > > > > > > >=20 > > > > > > > I've recently revised my draft on UA loose=20 > routing. You can > > > > > > pick it up > > > > > > > here: > > > > > > >=20 > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > > > > > se-route-01.txt > > > > > > >=20 > > > > > > > This draft is meant to fulfill one of our charter items: > > > > > > > Feb 2008 Delivering request-URI and parameters=20 > > > > > > > to UAS via proxy to > > > > > > > IESG (PS) > > > > > > >=20 > > > > > > > As folks may recall, the GRUU spec used to have these > > > > > things called > > > > > > > grids, which allowed a UA to add its own parameters to the > > > > > > GRUU before > > > > > > > handing it out. Several GRUU revisions back, this function > > > > > > got yanked > > > > > > > because it was recognized that the problem was=20 > more general > > > > > > than GRUU, > > > > > > > and would be useful for AOR as well. > > > > > > >=20 > > > > > > > Two IETFs back I presented this draft briefly during a > > > > > SIP session.=20 > > > > > > > There was a lot of interest and people liked it > > > > architecturally, > > > > > > > however there were two open issues that needed to get > > > > > > resolved. This > > > > > > > mail is meant to start discussion on one of them -=20 > > backwards=20 > > > > > > > compatibility. > > > > > > >=20 > > > > > > > THe mechanism basically changes the way proxies handle > > > > requests.=20 > > > > > > > Instead of rewriting the request URI for out-of-dialog > > > > requests, > > > > > > > they'll push a route header and leave the r-uri=20 > alone. This > > > > > > allows the > > > > > > > original R-URI and any parameters it contains to get > > > > > > delivered to the > > > > > > > UAS. > > > > > > >=20 > > > > > > > So, the main issue is, what kinds of backwards > > > > > > compatibility problems > > > > > > > will this cause. The draft provides a basic mechanism > > > > > whereby a UA > > > > > > > includes an option tag in the REGISTER, and the registrar > > > > > indicates > > > > > > > that it is using this mechanism or not. So we can > > > > negotiate this > > > > > > > between a UA and registrar easily. Now, the=20 > problem is with=20 > > > > > > > intermediate proxies. If there is an edge proxy=20 > between the > > > > > > UA and its > > > > > > > registrar, it will now see requests targeted to the UA, > > > > > > which contain > > > > > > > a Route header beyond itself, even though it=20 > thinks its the > > > > > > edge proxy > > > > > > > and the last point of contact before the UA. Technically, > > > > > > if this edge > > > > > > > proxy is compliant to rfc3261 it would work. However, the > > > > > > question is > > > > > > > whether proxies in the wild would properly work in=20 > > this case. > > > > > > >=20 > > > > > > > If folks can comment based on their own products,=20 > or their=20 > > > > > > > experiences, on whether they think this would work, or > > > > > > concerns they > > > > > > > have, that would be great. THere are solutions that would > > > > > > allow us to > > > > > > > disable the mechanism when intermediate proxies don't > > > > > > support it, but > > > > > > > they are more complex and I'd rather avoid it. > > > > > > >=20 > > > > > > > THanks, > > > > > > > Jonathan R. > > > > > > > --=20 > > > > > > > Jonathan D. Rosenberg, Ph.D. 600=20 > > > Lanidex Plaza > > > > > > > Cisco Fellow =20 > > Parsippany, NJ=20 > > > > > > > 07054-2711 > > > > > > > Cisco Systems > > > > > > > jdrosen@cisco.com FAX: =20 > > > > > (973) 952-5050 > > > > > > > http://www.jdrosen.net PHONE:=20 > > > > > (973) 952-5000 > > > > > > > http://www.cisco.com > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP=20 > > Protocol Use=20 > > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > > > sipping@ietf.org for new developments on the > > > application of sip > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > > > This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > > > sip-implementors@cs.columbia.edu for questions on > > > current sip Use > > > > > > sipping@ietf.org for new developments on the=20 > > application of sip > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 08:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyovN-00010Y-QV; Thu, 14 Jun 2007 08:59:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HyovM-0000zQ-2M for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 08:59:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyovL-0000yS-OG for sip@ietf.org; Thu, 14 Jun 2007 08:59:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyovK-0002Gi-Mp for sip@ietf.org; Thu, 14 Jun 2007 08:59:39 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 267BF20072; Thu, 14 Jun 2007 14:59:38 +0200 (CEST) X-AuditID: c1b4fb3e-b0678bb0000007e1-81-46713bbaaa20 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F3AB620FDD; Thu, 14 Jun 2007 14:59:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:59:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing Date: Thu, 14 Jun 2007 14:59:36 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054179F2@esealmw113.eemea.ericsson.se> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E6C8@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing thread-index: AcetZ0nsFl39U9cnSD2GoNTrmr3qVgAiOHeAAADi/SAAHJ7RQAAAiGYQAABcmGAAAgiTMAAEB2wwAABcPLA= References: <466F5E26.2000709@cisco.com> <5D1A7985295922448D5550C94DE29180012C9836@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF9423256705397552@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C99F6@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567054171DC@esealmw113.eemea.ericsson.se> <5D1A7985295922448D5550C94DE29180012C9A19@DEEXC1U01.de.lucent.com> A <7374777208BDC7449D5620EF94232567054174B3@esealmw113.eemea.ericsson.se> <0D5F89FAC29E2C41B98A6A762007F5D019E6C8@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg (JO/LMF)" To: "Elwell, John" , "DRAGE, Keith (Keith)" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 14 Jun 2007 12:59:37.0631 (UTC) FILETIME=[DD130AF0:01C7AE83] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi John,=20 >For clarification, does the P-Called-party header field URI=20 >get overwritten when retargeting (as opposed to routing)=20 >occurs? If not, I fear it suffers from the same problem as=20 >the To header field URI, as described in Jonathan's draft. I believe it does work with retargeting. In fact, chapter 4.2 of RFC3455 pretty much describes the same = retargeting problem when using the To header as Jonathan does in his = draft. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: 14 June 2007 12:03 > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing > >=20 > >=20 > > Hi, > >=20 > > >It is entirely appropriate at this stage to put forward=20 > alternatives.=20 > > >It is even more appropriate to do it now rather than in 6 months=20 > > >time. > > >=20 > > >However please do not expect the editor to elaborate them.=20 > If the WG=20 > > >has ideas, send text, either by individual author drafts,=20 > or by the=20 > > >mailing list. > >=20 > > Regarding the P-Called-Party header, there already IS an RFC=20 > > describing the header, and what it is used for. So, IF it already=20 > > solves the problem (RFC3455 does say that the header is=20 > used to convey=20 > > the AOR to the UAS), why would we need a separate draft? The only=20 > > additional information that a draft could contain are the use-cases=20 > > where receiving the AOR is important - but those use-cases are=20 > > solution independent and already described in Jonathan's draft. > >=20 > > Of course, if we want to define a NEW header, or a NEW URI=20 > parameter,=20 > > that may be done in a separate draft. > >=20 > > But, no matter how we do it, I think the author should at least=20 > > indicate whether he has already thought about the alternatives that=20 > > have been presented, and why he thinks that they don't work. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg (JO/LMF) > > > > [mailto:christer.holmberg@ericsson.com] > > > > Sent: Thursday, June 14, 2007 10:51 AM > > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > > Subject: RE: [Sip] UA Loose Routing > > > >=20 > > > >=20 > > > > Hi Keith, > > > >=20 > > > > The text you sent says: > > > >=20 > > > > "Consensus noted that we do need some sort of solution for > > > the general > > > > problem of delivery of URI parameters across contact-routing=20 > > > > operations." > > > >=20 > > > > I have no problems with that.=20 > > > >=20 > > > > I also have no problem with using Jonathan's draft as=20 > base line,=20 > > > > because the draft discusses the problem in a good way. > > > >=20 > > > > But, still: as the text says, the agreement was to come up > > > with SOME > > > > SORT OF SOLUTION, which to me does not mean that we have > > agreed to > > > > adopt the specific solution in Jonathan's draft. We > > should also be > > > > "allowed" to discuss alternative solutions, whether they > > > are based on > > > > P-Called-Party, some other header, some URI parameter, or > > > whatever...=20 > > > > Maybe those alternative solutions do not work, and then=20 > we should=20 > > > > describe that (as Jonathan has done for the To header- > > and History > > > > header alternatives). > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > > > Sent: 14. kes=E4kuuta 2007 12:40 > > > > > To: Christer Holmberg (JO/LMF); Jonathan Rosenberg; > > IETF SIP List > > > > > Subject: RE: [Sip] UA Loose Routing > > > > >=20 > > > > > You appear to be questioning whether the solution was > > > adopted. The > > > > > minutes state: > > > > >=20 > > > > >=20 > > >=20 > ------------------------------------------------------------------- > > > > > Topic: GRUU and Supporting Drafts =20 > > > > > Led by Jonathan Rosenberg > > > > > Slides included in proceedings > > > > > Read:=20 > > draft-ietf-sip-gruu-11,draft-rosenberg-sip-ua-loose-route-00 > > > > >=20 > > > > > Change since last version reviewed. > > > > >=20 > > > > > Issue: GRUU subtype names. The room demonstrated a slight > > > > preference > > > > > for the names used in -11 over known alternatives, but > > > nobody seems > > > > > particularly enamored with these names and the floor > > > > remains open to > > > > > suggestions. > > > > >=20 > > > > > Discussion on ua-loose-route draft deferred to next session. > > > > >=20 > > > > >=20 > > > > > Session 2: Friday 0900-1130 Grand Ballroom C > > > > >=20 > > > > >=20 > > > > > Topic: UA-loose-route, continued from previous session. > > > > >=20 > > > > > Consensus noted that we do need some sort of solution for > > > > the general > > > > > problem of delivery of URI parameters across contact-routing=20 > > > > > operations. > > > > >=20 > > > > > Issue: Concerns raised about backward compatibility.=20 > Noted that=20 > > > > > compliant P-CSCF should be OK. Suggested that we have a > > > > design team > > > > > revisit call-flows and analyze for backward > > compatibility issues. > > > > >=20 > > > > > Issue: Does GRUU normatively depend on this work? Resolved:=20 > > > > > GRUU does not reference this document. However, some > > > > participants feel > > > > > it should, as the benefit of GRUU cannot be fully > > > recognized in the > > > > > absence of this specification. The chairs asked for a > > > hum, and the > > > > > consensus of the room is that GRUU and ua-loose-route > > can proceed > > > > > independently. > > > > >=20 > > > > > Question: Adopt this draft as baseline text for a WG > > > effort, should > > > > > the ADs approve the milestone? Consensus to adopt noted > > by chairs. > > > > > To-do: Chairs to work with AD to set new milestone. > > > > >=20 > > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > > >=20 > > > > > The minutes quite clearly say "Adopt this draft as baseline > > > > text for a > > > > > WG effort" and given that the charter item now exists, then > > > > I believe > > > > > that we are entitled to call for the editor (Jonathan) to > > > > submit the > > > > > current text as draft-ietf-sip-ua-loose-route. > > > > >=20 > > > > > I agree the file name says loose-route, but I don'y think > > > we should > > > > > change that. After all, we lose that filename when it gets > > > > published > > > > > as an RFC anyway. > > > > >=20 > > > > > The charter item states > > > > >=20 > > > > > Dec 2007 Delivering request-URI and parameters to UAS via=20 > > > > > proxy to WGLC =20 > > > > > Feb 2008 Delivering request-URI and parameters to UAS via=20 > > > > > proxy to IESG (PS) =20 > > > > >=20 > > > > > I assume that you are OK with this. > > > > >=20 > > > > > What I would suggest is that you address specific > > comments to the > > > > > title of the deliverable: > > > > >=20 > > > > > Applying Loose Routing to Session Initiation Protocol > > > > > (SIP) User Agents (UA) > > > > >=20 > > > > > And to the abstract: > > > > >=20 > > > > > Abstract > > > > >=20 > > > > > A key part of the behavior of the Session Initiation > > > > Protocol (SIP) > > > > > is that SIP proxies rewrite the Request-URI as a > > request moves > > > > > throughout the network. Over the years, experience has > > > > shown this > > > > > to > > > > > be problematic. It makes it difficult to use > > Request URI for > > > > > service > > > > > invocation, complicates emergency services, makes it > > > > more complex > > > > > to > > > > > support aliases, and so on. Architecturally, it > > confounds the > > > > > concepts of address and route. This document proposes > > > to change > > > > > this > > > > > through a new mechanism called UA loose routing. > > > > >=20 > > > > > As you think appropriate to your concerns. > > > > >=20 > > > > > Alternatively, if you (or indeed any other SIP WG member) > > > do have a > > > > > completely different solution, then there is still time > > > to post an > > > > > individual draft or post a skeleton of a mechanism to=20 > the list. > > > > >=20 > > > > > Regards > > > > >=20 > > > > > Keith > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg (JO/LMF)=20 > > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: Wednesday, June 13, 2007 8:52 PM > > > > > > To: DRAGE, Keith (Keith); Jonathan Rosenberg; IETF SIP List > > > > > > Subject: RE: [Sip] UA Loose Routing > > > > > >=20 > > > > > >=20 > > > > > > Hi, > > > > > >=20 > > > > > > We can call it loose route if we want, but I think the > > > > > initial focus > > > > > > should be the problem we are going to solve (I don't think > > > > > we agreed > > > > > > on a specific solution at #67), and we should look into > > > > alternative > > > > > > solutions (the draft does that in some extent, but > > > other possible > > > > > > alternatives have also been mentioned). > > > > > >=20 > > > > > > Or, do you prefer to have separate drafts describing > > > alternative > > > > > > solutions for the problem? > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > Christer > > > > > >=20 > > > > > > =20 > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: DRAGE, Keith (Keith)=20 > [mailto:drage@alcatel-lucent.com] > > > > > > > Sent: 13. kes=E4kuuta 2007 22:25 > > > > > > > To: Jonathan Rosenberg; IETF SIP List > > > > > > > Subject: RE: [Sip] UA Loose Routing > > > > > > >=20 > > > > > > > (As WG chair) > > > > > > >=20 > > > > > > > As well as agreeing to charter the item, we=20 > actually agreed > > > > > > at IETF#67 > > > > > > > that this draft was a suitable candidate to fulfil that > > > > > > charter item. > > > > > > >=20 > > > > > > > Therefore unless issues are raised with this, I would > > > > request the > > > > > > > editor (as Jonathan is editor) to submit the next > > > > version of this > > > > > > > document as draft-ietf-sip-ua-loose-route-00. > > > > > > >=20 > > > > > > > Regards > > > > > > >=20 > > > > > > > Keith > > > > > > >=20 > > > > > > > > -----Original Message----- > > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > > > > > > Sent: Wednesday, June 13, 2007 4:02 AM > > > > > > > > To: IETF SIP List > > > > > > > > Subject: [Sip] UA Loose Routing Issue #1: Backwards > > > > > compatibility > > > > > > > >=20 > > > > > > > > I've recently revised my draft on UA loose > > routing. You can > > > > > > > pick it up > > > > > > > > here: > > > > > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-ua-loo > > > > > > > > se-route-01.txt > > > > > > > >=20 > > > > > > > > This draft is meant to fulfill one of our charter items: > > > > > > > > Feb 2008 Delivering request-URI=20 > and parameters=20 > > > > > > > > to UAS via proxy to > > > > > > > > IESG (PS) > > > > > > > >=20 > > > > > > > > As folks may recall, the GRUU spec used to have these > > > > > > things called > > > > > > > > grids, which allowed a UA to add its own=20 > parameters to the > > > > > > > GRUU before > > > > > > > > handing it out. Several GRUU revisions back,=20 > this function > > > > > > > got yanked > > > > > > > > because it was recognized that the problem was > > more general > > > > > > > than GRUU, > > > > > > > > and would be useful for AOR as well. > > > > > > > >=20 > > > > > > > > Two IETFs back I presented this draft briefly during a > > > > > > SIP session.=20 > > > > > > > > There was a lot of interest and people liked it > > > > > architecturally, > > > > > > > > however there were two open issues that needed to get > > > > > > > resolved. This > > > > > > > > mail is meant to start discussion on one of them - > > > backwards > > > > > > > > compatibility. > > > > > > > >=20 > > > > > > > > THe mechanism basically changes the way proxies handle > > > > > requests.=20 > > > > > > > > Instead of rewriting the request URI for out-of-dialog > > > > > requests, > > > > > > > > they'll push a route header and leave the r-uri > > alone. This > > > > > > > allows the > > > > > > > > original R-URI and any parameters it contains to get > > > > > > > delivered to the > > > > > > > > UAS. > > > > > > > >=20 > > > > > > > > So, the main issue is, what kinds of backwards > > > > > > > compatibility problems > > > > > > > > will this cause. The draft provides a basic mechanism > > > > > > whereby a UA > > > > > > > > includes an option tag in the REGISTER, and the=20 > registrar > > > > > > indicates > > > > > > > > that it is using this mechanism or not. So we can > > > > > negotiate this > > > > > > > > between a UA and registrar easily. Now, the > > problem is with > > > > > > > > intermediate proxies. If there is an edge proxy > > between the > > > > > > > UA and its > > > > > > > > registrar, it will now see requests targeted to the UA, > > > > > > > which contain > > > > > > > > a Route header beyond itself, even though it > > thinks its the > > > > > > > edge proxy > > > > > > > > and the last point of contact before the UA.=20 > Technically, > > > > > > > if this edge > > > > > > > > proxy is compliant to rfc3261 it would work.=20 > However, the > > > > > > > question is > > > > > > > > whether proxies in the wild would properly work in > > > this case. > > > > > > > >=20 > > > > > > > > If folks can comment based on their own products, > > or their > > > > > > > > experiences, on whether they think this would work, or > > > > > > > concerns they > > > > > > > > have, that would be great. THere are solutions=20 > that would > > > > > > > allow us to > > > > > > > > disable the mechanism when intermediate proxies don't > > > > > > > support it, but > > > > > > > > they are more complex and I'd rather avoid it. > > > > > > > >=20 > > > > > > > > THanks, > > > > > > > > Jonathan R. > > > > > > > > --=20 > > > > > > > > Jonathan D. Rosenberg, Ph.D. 600=20 > > > > Lanidex Plaza > > > > > > > > Cisco Fellow =20 > > > Parsippany, NJ > > > > > > > > 07054-2711 > > > > > > > > Cisco Systems > > > > > > > > jdrosen@cisco.com FAX: =20 > > > > > > (973) 952-5050 > > > > > > > > http://www.jdrosen.net PHONE:=20 > > > > > > (973) 952-5000 > > > > > > > > http://www.cisco.com > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > > This list is for NEW development of the core SIP > > > Protocol Use > > > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > > current sip Use > > > > > > > > sipping@ietf.org for new developments on the > > > > application of sip > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > Sip mailing list =20 > https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP > > Protocol Use > > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > > > sipping@ietf.org for new developments on the > > > application of sip > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 11:03:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqr9-0005Ju-0T; Thu, 14 Jun 2007 11:03:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyqr7-0005JX-TS for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 11:03:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqr7-0005Ia-Hn for sip@ietf.org; Thu, 14 Jun 2007 11:03:25 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyqr6-0007E7-NZ for sip@ietf.org; Thu, 14 Jun 2007 11:03:25 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 14 Jun 2007 08:03:23 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="18930739:sNHT67145672" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 16:03:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Thu, 14 Jun 2007 16:03:16 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceuE8ClpGEQwgJ+TJadt5mIfc2stwASndSwAAHyZBAAAFUPwAAAf5LgAAAo02AABJQ4IAAAwhYAAAThKTA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2 C41B98 A6 A762007F5 D 019E677"@GBN THT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" , "Elwell, John" X-OriginalArrivalTime: 14 Jun 2007 15:03:22.0390 (UTC) FILETIME=[26935B60:01C7AE95] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer,=20 I think I'm starting to see your point... It sounds to me as if you are saying something equivalent to the = following: INFO is a notification for some type of implicit subscription on an = INVITE dialog. (geez, I hope my interpretation doesn't sound stupid) For example, instead of establishing a new dialog for receiving DTMF = notifications, the INFO is used in order to send events on the INVITE = dialog without requiring a new subscription usage on the dialog = (meaning, the implicit subscription ends with the BYE, unlike explicit = subscriptions which are a different usage). Is this interpretation acceptable? Only thing part I feel is missing is actually stating which = "subscriptions" the UAs want to receive/support and the previous = discussion on content-type vs. another header to indicate the purpose of = the INFO message. If DTMF on INFO does become a known RFC, I think for the very least it = should adopt the body from the KPML syntax rather than a proprietary = one, but that's another issue. Regards, Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) = [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 14, 2007 3:38 PM > To: Elwell, John > Cc: SIP IETF > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi John >=20 > >>I am personally not saying people should use one solution instead of > >>another. I think the issue is that the market has seen a need for > >>out-of-band transport of DTMF tones, one reason being that all > >>entities using DTMF do not have access to the media. > >[JRE] KPML addresses this space. Because it establishes a > >dialog for the purpose, KPML can ensure that SIPS is used, > >even if SIPS is not used for the INVITE-initiated dialog. > >Why do we need a different solution? >=20 > The problem is that the INFO solution was implemented BEFORE KPML was > finalized. >=20 > I also believe that many people think it's easier do handle it in a = single > dialog, without having to establish and associate two separate ones. = But, > that's just my guessing (I have personally never had to make the = decisson > which solution to implement based on technical arguments). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > > > > > -----Original Message----- > > > > > From: Christer Holmberg (JO/LMF) > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: 14 June 2007 10:41 > > > > > To: Elwell, John > > > > > Cc: SIP IETF > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > dialog usage? > > > > > > > > > > > > > > > Hi John, > > > > > > > > > > I hear what you are saying, but I don't see how this is > > > specific to > > > > > DTMF and INFO. > > > > > > > > > > Doesn't this affect all I kind of sensitive information > > > > that you want > > > > > to transport over SIP? > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Elwell, John [mailto:john.elwell@siemens.com] > > > > > > Sent: 14. kes=E4kuuta 2007 12:33 > > > > > > To: Christer Holmberg (JO/LMF) > > > > > > Cc: SIP IETF > > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > > dialog usage? > > > > > > > > > > > > Christer, > > > > > > > > > > > > Slightly aside from the main direction of the discussion, > > > > but what > > > > > > about security? I send my audio using SRTP, and would > > > > expect DTMF to > > > > > > receive exactly the same protection. The signalling may > > > > or may not > > > > > > be end-to-end secured, depending on which of the current > > > > and future > > > > > > key management methods are used. Maybe SIPS has to be > > > > used, but we > > > > > > all know the limitations of that (e.g., if I receive > > an INVITE > > > > > > request to my SIPS URI, can I be sure all hops are > > > > secured?). I am > > > > > > sure the IETF would not want to endorse a mechanism that > > > > opens up a > > > > > > security hole that is not present with an existing > > > mechanism for > > > > > > doing the same thing (RFC 2833). > > > > > > > > > > > > John > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg (JO/LMF) > > > > > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: 14 June 2007 10:20 > > > > > > > To: Paul Kyzivat > > > > > > > Cc: SIP IETF; Dean Willis > > > > > > > Subject: RE: [Sip] INFO message belongs only to INVITE > > > > > dialog usage? > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > >>I don't think an application will trigger INFOs in a > > > > > > spray and pray > > > > > > > >>matter. You will only send media server control messages > > > > > > if you are > > > > > > > >>communicating with a media server control > > application that > > > > > > > >>understands them. > > > > > > > > > > > > > > > >How does my phone know it is communicating with a media > > > > > > server that > > > > > > > >understands INFO for conveying DTMF? The thing I call > > > > > may indicate > > > > > > > >support of INFO because it supports qsig tunneling. > > > > > > > > > > > > > > It should also indicate support (using the Accept > > > > header) of the > > > > > > > content-type which is used to transport the media control > > > > > messages. > > > > > > > > > > > > > > >>>Before you send a DTMF/INFO, you really need to > > > know that the > > > > > > > recipient understands DTMF/INFO in general and the > > > > > > > >>>specific encoding of DTMF in INFO that you're > > using (there > > > > > > > have been > > > > > > > >>>multiple encodings proposed). > > > > > > > >> > > > > > > > >>Yes, and you know that if you receive an indication > > > > > from the other > > > > > > > party that he supports application/my-dtmf (or whatever > > > > > > > >value is used). > > > > > > > >> > > > > > > > >>And, if we would have standardized one encoding, maybe > > > > > > > there wouldn't > > > > > > > >>be multiple ones out there... > > > > > > > > > > > > > > > >We currently have no way to say "I support mime-type foo > > > > > > for use with > > > > > > > >disposition bar and method baz", but in reality that is > > > > > > going to be > > > > > > > >the situation. I support sdp for disposition "session" in > > > > > > the methods > > > > > > > >that convey o/a. But I don't support sdp in MESSAGE > > > or INFO. I > > > > > > > >support text/plain with > > > > > > > content-type "render" > > > > > > > in MESSAGE, but not for other > > > > > > > >dispositions and other message types. > > > > > > > > > > > > > > You don't have any way to say "I support mime-type SDP > > > > > for use with > > > > > > > disposition bar and method baz" either - that we specify > > > > > elsewhere. > > > > > > > > > > > > > > And, if we define a DTMF mime-type, we should of course > > > > > also say in > > > > > > > which SIP message it can be used etc. But, again, we > > > should not > > > > > > > specify the applications that are going to use it. > > > > > > > > > > > > > > Also, since INFO is not supposed to affect the SIP > > > > > session, we can > > > > > > > also put restrictions on which disposition values are to = be > > > > > > used etc. > > > > > > > > > > > > > > So, of course there is some work to do, but that's not a > > > > > reason to > > > > > > > reject something. If everything was done and ready, there > > > > > > would be no > > > > > > > need for the SIP WG :) > > > > > > > > > > > > > > >Getting an indication of support for application/my-dtmf > > > > > is useful > > > > > > > >*if* you know that the UA sending it to you always uses = it > > > > > > the same > > > > > > > >ways you do. You can only know that if you control it, or > > > > > > if all the > > > > > > > >uses of that type are standardized. > > > > > > > > > > > > > > It's up to the applications to make sure that the DTMFs = are > > > > > > sent and > > > > > > > intepreted. If the receiving application has not asked for > > > > > > DTMFs, and > > > > > > > the sender still sends them, the receiver should simply > > > > > > discard them. > > > > > > > It's part of the application logic - not the SIP > > > > > protocol. The SIP > > > > > > > protocol defines information elements to indicate what > > > > > > content types > > > > > > > you support, what actions to take if the content type is > > > > > > not supported > > > > > > > etc. > > > > > > > But, again: we don't specify what the applicatons are = going > > > > > > to do with > > > > > > > information. > > > > > > > > > > > > > > It's similar to when you use RFC2833 for sending DTMFs. = The > > > > > > only thing > > > > > > > you do, as part of the offer/answer procedure, is agreeing > > > > > > that both > > > > > > > endpoints support RFC2833 - but you do not specify what = the > > > > > > endpoints > > > > > > > are going to do with the tones, when they will be sent = etc. > > > > > > > > > > > > > > >>>And beyond just understanding your encoding of = DTMF/INFO, > > > > > > > you need to > > > > > > > > > > > > > > >>>know that the recipient you are sending it to is > > > > likely to do > > > > > > > >>>something useful with that INFO, and that this = "something > > > > > > > useful" is > > > > > > > >>>what you intend it to do when you send it. > > > > > > > >> > > > > > > > >>Yes, but you wouldn't send it unless you have a reason = to > > > > > > think the > > > > > > > >>receiver is going to do something with it, e.g. if you > > > > > have been > > > > > > > >>asked to give your PIN code. > > > > > > > >> > > > > > > > >>I don't understand why people think that applications > > > > > would start > > > > > > > >>sending all kind of INFOs "just for fun", without any > > > > > > logic behind. > > > > > > > >>I have never seen that happen in real world deployments. = I > > > > > > > wouldn't > > > > > > > >>start sending UPDATEs and/or re-INVITEs just for > > > fun either, > > > > > > > >>eventhough there is nothing preventing me from doing it. > > > > > > > > > > > > > > > >Lets go back to my phone. *It* doesn't know that I have > > > > > > been asked to > > > > > > > >give my PIN code, even though I do. All my phone knows is > > > > > > that I have > > > > > > > >pressed one of the buttons on the keypad. It may > > > > > reasonably infer > > > > > > > >that I want *something* to be done with them, and > > > > > probably that I > > > > > > > >want them sent to the other end in some way. It has no > > > > > > idea *how* (or > > > > > > > >*if*) the other end is prepared to receive them. > > > > > > > > > > > > > > I think what you are talking about is how you will design > > > > > your SIP > > > > > > > phone. > > > > > > > > > > > > > > For example, on my table phone, if I during a call want to > > > > > > send DTMF > > > > > > > tones I have to first press one button to "active" DTMF, > > > > > > and then any > > > > > > > button I sent is sent as DTMF. If I am asked to give my = PIN > > > > > > code, but > > > > > > > do not active DTMF, nothing will happen when I press > > > > the buttons. > > > > > > > > > > > > > > On my GSM phone, however, I don't need to active DTMF. If = I > > > > > > am asked > > > > > > > to give my PIN code, I simply press buttons and they are > > > > > > sent as DTMF > > > > > > > tones. > > > > > > > > > > > > > > >For instance, it may have indicated support for a mime > > > > > > type that my > > > > > > > >phone knows how to use to encode DTMF. But its possible = it > > > > > > was really > > > > > > > >trying to say that it would support that type in a > > > > > NOTIFY (sent or > > > > > > > >received). > > > > > > > > > > > > > > IF there are missing parts in the negotiation mechanism, > > > > > we need to > > > > > > > fix that. > > > > > > > > > > > > > > Something like: > > > > > > > > > > > > > > Accept: application/my-dtmf;method=3DINFO > > > > > > > > > > > > > > OR, in the draft defining the content type, we specify > > > > > that content > > > > > > > type X can only be sent using this and that method. I > > > > > > belive we do the > > > > > > > same thing for SDP. > > > > > > > > > > > > > > But, so far we haven't been interested in looking into > > > > > > these issues. > > > > > > > We just say that using INFO is against the spirit of SIP, > > > > > it causes > > > > > > > all kind of problems etc etc. > > > > > > > > > > > > > > My intention is not to "promote" the usage of INFO. My > > > > > > issue is that > > > > > > > the market has found and deployed an easy and effective = way > > > > > > of doing > > > > > > > things using INFO, without breaking the protocol, and what > > > > > > worries me > > > > > > > is that instead of trying to help the market (e.g. by > > > > > standardizing > > > > > > > the content types, providing negotiation mechanism > > to achieve > > > > > > > interoperability), and in that way indirectly help them > > > > > to come up > > > > > > > with new SIP applications, we simply tell them that > > > > what they are > > > > > > > doing (and have been doing for > > > > > > > years) is wrong, that they are breaking SIP, etc etc etc. > > > > > > > > > > > > > > And, if we really wanted to restrict the usage of INFO, it > > > > > > should have > > > > > > > been done a long time ago - not years after the INFO RFC = is > > > > > > published > > > > > > > and people have deployed usages of it. > > > > > > > > > > > > > > Anyway, I guess we can go on with this discussion > > > > > forever. Maybe we > > > > > > > should find some time in Chicago and sit down and > > > discuss this? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Sip mailing list = https://www1.ietf.org/mailman/listinfo/sip > > > > > > > This list is for NEW development of the core SIP > > Protocol Use > > > > > > > sip-implementors@cs.columbia.edu for questions on > > > > current sip Use > > > > > > > sipping@ietf.org for new developments on the > > > application of sip > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 13:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyskp-0000Yp-QH; Thu, 14 Jun 2007 13:05:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyskn-0000WO-Hv for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 13:05:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyskn-0000Vf-6y for sip@ietf.org; Thu, 14 Jun 2007 13:05:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyskm-0000C7-HZ for sip@ietf.org; Thu, 14 Jun 2007 13:05:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Jun 2007 13:05:00 -0400 X-IronPort-AV: i="4.16,421,1175486400"; d="scan'208"; a="123634422:sNHT87530648" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5EH508J000445; Thu, 14 Jun 2007 13:05:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5EH4x61016071; Thu, 14 Jun 2007 17:05:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:04:51 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 13:04:51 -0400 Message-ID: <46717533.6080609@cisco.com> Date: Thu, 14 Jun 2007 13:04:51 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gilad Shaham Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2 C41B98 A6 A762007F5 D 019E677"@GBN THT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Jun 2007 17:04:51.0392 (UTC) FILETIME=[1F28CC00:01C7AEA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14031; t=1181840700; x=1182704700; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20Gilad=20Shaham=20; bh=85Qa2NPON5uhIJgYwauxU3KVcHtVkIXD9Osa2g5G5fw=; b=mswq5ycpTJ1n/rOozVGgMLF8JkuC5cdd3kZF+Y4t/1C2V27MY8sS/BRf3grWNUeCaE3eNWdT Ddtw90nzQUxaM9U7ksBt5FcLFdTdXKhO+jotqFdwAdbpjn+56/+BK2in; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: SIP IETF , "Elwell, John" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org If you start down this path (I'd rather not), then rather than considering INFO to be a notification of an implicit subscription you might was well use NOTIFY for an implicit subscription. Just as there is a lot of use of INFO in the wild, there is also a lot of use of NOTIFY without SUBSCRIBE. I find it pretty difficult viewing INFO as an implicit NOTIFY. Paul Gilad Shaham wrote: > Christer, > I think I'm starting to see your point... > > It sounds to me as if you are saying something equivalent to the following: > INFO is a notification for some type of implicit subscription on an INVITE dialog. > (geez, I hope my interpretation doesn't sound stupid) > > For example, instead of establishing a new dialog for receiving DTMF notifications, the INFO is used in order to send events on the INVITE dialog without requiring a new subscription usage on the dialog (meaning, the implicit subscription ends with the BYE, unlike explicit subscriptions which are a different usage). > > Is this interpretation acceptable? > > Only thing part I feel is missing is actually stating which "subscriptions" the UAs want to receive/support and the previous discussion on content-type vs. another header to indicate the purpose of the INFO message. > > > If DTMF on INFO does become a known RFC, I think for the very least it should adopt the body from the KPML syntax rather than a proprietary one, but that's another issue. > > > Regards, > Gilad > >> -----Original Message----- >> From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, June 14, 2007 3:38 PM >> To: Elwell, John >> Cc: SIP IETF >> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >> >> >> Hi John >> >>>> I am personally not saying people should use one solution instead of >>>> another. I think the issue is that the market has seen a need for >>>> out-of-band transport of DTMF tones, one reason being that all >>>> entities using DTMF do not have access to the media. >>> [JRE] KPML addresses this space. Because it establishes a >>> dialog for the purpose, KPML can ensure that SIPS is used, >>> even if SIPS is not used for the INVITE-initiated dialog. >>> Why do we need a different solution? >> The problem is that the INFO solution was implemented BEFORE KPML was >> finalized. >> >> I also believe that many people think it's easier do handle it in a single >> dialog, without having to establish and associate two separate ones. But, >> that's just my guessing (I have personally never had to make the decisson >> which solution to implement based on technical arguments). >> >> Regards, >> >> Christer >> >> >> >> >> >> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg (JO/LMF) >>>>>> [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: 14 June 2007 10:41 >>>>>> To: Elwell, John >>>>>> Cc: SIP IETF >>>>>> Subject: RE: [Sip] INFO message belongs only to INVITE >>>> dialog usage? >>>>>> >>>>>> Hi John, >>>>>> >>>>>> I hear what you are saying, but I don't see how this is >>>> specific to >>>>>> DTMF and INFO. >>>>>> >>>>>> Doesn't this affect all I kind of sensitive information >>>>> that you want >>>>>> to transport over SIP? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens.com] >>>>>>> Sent: 14. kesäkuuta 2007 12:33 >>>>>>> To: Christer Holmberg (JO/LMF) >>>>>>> Cc: SIP IETF >>>>>>> Subject: RE: [Sip] INFO message belongs only to INVITE >>>>> dialog usage? >>>>>>> Christer, >>>>>>> >>>>>>> Slightly aside from the main direction of the discussion, >>>>> but what >>>>>>> about security? I send my audio using SRTP, and would >>>>> expect DTMF to >>>>>>> receive exactly the same protection. The signalling may >>>>> or may not >>>>>>> be end-to-end secured, depending on which of the current >>>>> and future >>>>>>> key management methods are used. Maybe SIPS has to be >>>>> used, but we >>>>>>> all know the limitations of that (e.g., if I receive >>> an INVITE >>>>>>> request to my SIPS URI, can I be sure all hops are >>>>> secured?). I am >>>>>>> sure the IETF would not want to endorse a mechanism that >>>>> opens up a >>>>>>> security hole that is not present with an existing >>>> mechanism for >>>>>>> doing the same thing (RFC 2833). >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Christer Holmberg (JO/LMF) >>>>>>>> [mailto:christer.holmberg@ericsson.com] >>>>>>>> Sent: 14 June 2007 10:20 >>>>>>>> To: Paul Kyzivat >>>>>>>> Cc: SIP IETF; Dean Willis >>>>>>>> Subject: RE: [Sip] INFO message belongs only to INVITE >>>>>> dialog usage? >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>>> I don't think an application will trigger INFOs in a >>>>>>> spray and pray >>>>>>>>>> matter. You will only send media server control messages >>>>>>> if you are >>>>>>>>>> communicating with a media server control >>> application that >>>>>>>>>> understands them. >>>>>>>>> How does my phone know it is communicating with a media >>>>>>> server that >>>>>>>>> understands INFO for conveying DTMF? The thing I call >>>>>> may indicate >>>>>>>>> support of INFO because it supports qsig tunneling. >>>>>>>> It should also indicate support (using the Accept >>>>> header) of the >>>>>>>> content-type which is used to transport the media control >>>>>> messages. >>>>>>>>>>> Before you send a DTMF/INFO, you really need to >>>> know that the >>>>>>>> recipient understands DTMF/INFO in general and the >>>>>>>>>>> specific encoding of DTMF in INFO that you're >>> using (there >>>>>>>> have been >>>>>>>>>>> multiple encodings proposed). >>>>>>>>>> Yes, and you know that if you receive an indication >>>>>> from the other >>>>>>>> party that he supports application/my-dtmf (or whatever >>>>>>>>> value is used). >>>>>>>>>> And, if we would have standardized one encoding, maybe >>>>>>>> there wouldn't >>>>>>>>>> be multiple ones out there... >>>>>>>>> We currently have no way to say "I support mime-type foo >>>>>>> for use with >>>>>>>>> disposition bar and method baz", but in reality that is >>>>>>> going to be >>>>>>>>> the situation. I support sdp for disposition "session" in >>>>>>> the methods >>>>>>>>> that convey o/a. But I don't support sdp in MESSAGE >>>> or INFO. I >>>>>>>>> support text/plain with >>>>>>>> content-type "render" >>>>>>>> in MESSAGE, but not for other >>>>>>>>> dispositions and other message types. >>>>>>>> You don't have any way to say "I support mime-type SDP >>>>>> for use with >>>>>>>> disposition bar and method baz" either - that we specify >>>>>> elsewhere. >>>>>>>> And, if we define a DTMF mime-type, we should of course >>>>>> also say in >>>>>>>> which SIP message it can be used etc. But, again, we >>>> should not >>>>>>>> specify the applications that are going to use it. >>>>>>>> >>>>>>>> Also, since INFO is not supposed to affect the SIP >>>>>> session, we can >>>>>>>> also put restrictions on which disposition values are to be >>>>>>> used etc. >>>>>>>> So, of course there is some work to do, but that's not a >>>>>> reason to >>>>>>>> reject something. If everything was done and ready, there >>>>>>> would be no >>>>>>>> need for the SIP WG :) >>>>>>>> >>>>>>>>> Getting an indication of support for application/my-dtmf >>>>>> is useful >>>>>>>>> *if* you know that the UA sending it to you always uses it >>>>>>> the same >>>>>>>>> ways you do. You can only know that if you control it, or >>>>>>> if all the >>>>>>>>> uses of that type are standardized. >>>>>>>> It's up to the applications to make sure that the DTMFs are >>>>>>> sent and >>>>>>>> intepreted. If the receiving application has not asked for >>>>>>> DTMFs, and >>>>>>>> the sender still sends them, the receiver should simply >>>>>>> discard them. >>>>>>>> It's part of the application logic - not the SIP >>>>>> protocol. The SIP >>>>>>>> protocol defines information elements to indicate what >>>>>>> content types >>>>>>>> you support, what actions to take if the content type is >>>>>>> not supported >>>>>>>> etc. >>>>>>>> But, again: we don't specify what the applicatons are going >>>>>>> to do with >>>>>>>> information. >>>>>>>> >>>>>>>> It's similar to when you use RFC2833 for sending DTMFs. The >>>>>>> only thing >>>>>>>> you do, as part of the offer/answer procedure, is agreeing >>>>>>> that both >>>>>>>> endpoints support RFC2833 - but you do not specify what the >>>>>>> endpoints >>>>>>>> are going to do with the tones, when they will be sent etc. >>>>>>>> >>>>>>>>>>> And beyond just understanding your encoding of DTMF/INFO, >>>>>>>> you need to >>>>>>>> >>>>>>>>>>> know that the recipient you are sending it to is >>>>> likely to do >>>>>>>>>>> something useful with that INFO, and that this "something >>>>>>>> useful" is >>>>>>>>>>> what you intend it to do when you send it. >>>>>>>>>> Yes, but you wouldn't send it unless you have a reason to >>>>>>> think the >>>>>>>>>> receiver is going to do something with it, e.g. if you >>>>>> have been >>>>>>>>>> asked to give your PIN code. >>>>>>>>>> >>>>>>>>>> I don't understand why people think that applications >>>>>> would start >>>>>>>>>> sending all kind of INFOs "just for fun", without any >>>>>>> logic behind. >>>>>>>>>> I have never seen that happen in real world deployments. I >>>>>>>> wouldn't >>>>>>>>>> start sending UPDATEs and/or re-INVITEs just for >>>> fun either, >>>>>>>>>> eventhough there is nothing preventing me from doing it. >>>>>>>>> Lets go back to my phone. *It* doesn't know that I have >>>>>>> been asked to >>>>>>>>> give my PIN code, even though I do. All my phone knows is >>>>>>> that I have >>>>>>>>> pressed one of the buttons on the keypad. It may >>>>>> reasonably infer >>>>>>>>> that I want *something* to be done with them, and >>>>>> probably that I >>>>>>>>> want them sent to the other end in some way. It has no >>>>>>> idea *how* (or >>>>>>>>> *if*) the other end is prepared to receive them. >>>>>>>> I think what you are talking about is how you will design >>>>>> your SIP >>>>>>>> phone. >>>>>>>> >>>>>>>> For example, on my table phone, if I during a call want to >>>>>>> send DTMF >>>>>>>> tones I have to first press one button to "active" DTMF, >>>>>>> and then any >>>>>>>> button I sent is sent as DTMF. If I am asked to give my PIN >>>>>>> code, but >>>>>>>> do not active DTMF, nothing will happen when I press >>>>> the buttons. >>>>>>>> On my GSM phone, however, I don't need to active DTMF. If I >>>>>>> am asked >>>>>>>> to give my PIN code, I simply press buttons and they are >>>>>>> sent as DTMF >>>>>>>> tones. >>>>>>>> >>>>>>>>> For instance, it may have indicated support for a mime >>>>>>> type that my >>>>>>>>> phone knows how to use to encode DTMF. But its possible it >>>>>>> was really >>>>>>>>> trying to say that it would support that type in a >>>>>> NOTIFY (sent or >>>>>>>>> received). >>>>>>>> IF there are missing parts in the negotiation mechanism, >>>>>> we need to >>>>>>>> fix that. >>>>>>>> >>>>>>>> Something like: >>>>>>>> >>>>>>>> Accept: application/my-dtmf;method=INFO >>>>>>>> >>>>>>>> OR, in the draft defining the content type, we specify >>>>>> that content >>>>>>>> type X can only be sent using this and that method. I >>>>>>> belive we do the >>>>>>>> same thing for SDP. >>>>>>>> >>>>>>>> But, so far we haven't been interested in looking into >>>>>>> these issues. >>>>>>>> We just say that using INFO is against the spirit of SIP, >>>>>> it causes >>>>>>>> all kind of problems etc etc. >>>>>>>> >>>>>>>> My intention is not to "promote" the usage of INFO. My >>>>>>> issue is that >>>>>>>> the market has found and deployed an easy and effective way >>>>>>> of doing >>>>>>>> things using INFO, without breaking the protocol, and what >>>>>>> worries me >>>>>>>> is that instead of trying to help the market (e.g. by >>>>>> standardizing >>>>>>>> the content types, providing negotiation mechanism >>> to achieve >>>>>>>> interoperability), and in that way indirectly help them >>>>>> to come up >>>>>>>> with new SIP applications, we simply tell them that >>>>> what they are >>>>>>>> doing (and have been doing for >>>>>>>> years) is wrong, that they are breaking SIP, etc etc etc. >>>>>>>> >>>>>>>> And, if we really wanted to restrict the usage of INFO, it >>>>>>> should have >>>>>>>> been done a long time ago - not years after the INFO RFC is >>>>>>> published >>>>>>>> and people have deployed usages of it. >>>>>>>> >>>>>>>> Anyway, I guess we can go on with this discussion >>>>>> forever. Maybe we >>>>>>>> should find some time in Chicago and sit down and >>>> discuss this? >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP >>> Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>> current sip Use >>>>>>>> sipping@ietf.org for new developments on the >>>> application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 13:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytU6-0003jh-EY; Thu, 14 Jun 2007 13:51:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HytU6-0003jc-0v for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 13:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytU5-0003jU-Nh for sip@ietf.org; Thu, 14 Jun 2007 13:51:49 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytU3-0003Tt-Fv for sip@ietf.org; Thu, 14 Jun 2007 13:51:49 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070614175146m14006e8mke>; Thu, 14 Jun 2007 17:51:46 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l5EHpj8t001816 for ; Thu, 14 Jun 2007 13:51:45 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l5EHpjlo001812; Thu, 14 Jun 2007 13:51:45 -0400 Date: Thu, 14 Jun 2007 13:51:45 -0400 Message-Id: <200706141751.l5EHpjlo001812@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46717533.6080609@cisco.com> (pkyzivat@cisco.com) Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2 C41B98 A6 A762007F5 D 019E677"@GBN THT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> <46717533.6080609@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Paul Kyzivat If you start down this path (I'd rather not), then rather than considering INFO to be a notification of an implicit subscription you might was well use NOTIFY for an implicit subscription. In particular, NOTIFY is labeled with an event-type, so the recipient knows whether or not it knows how to process the event. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 16:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywNt-0004wj-BW; Thu, 14 Jun 2007 16:57:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HywNr-0004vv-Kq for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywNr-0004vn-AK for sip@ietf.org; Thu, 14 Jun 2007 16:57:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HywNr-0008DC-0o for sip@ietf.org; Thu, 14 Jun 2007 16:57:35 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HywNa-0002vS-1X; Thu, 14 Jun 2007 15:57:18 -0500 From: "Brian Rosen" To: "'Christer Holmberg \(JO/LMF\)'" , "'Ted Hardie'" , "'Jonathan Rosenberg'" , "'IETF SIP List'" References: <466F5E26.2000709@cisco.com><7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397563@esealmw113.eemea.ericsson.se> Subject: RE: [Sip] UA Loose Routing: Emergency example Date: Thu, 14 Jun 2007 16:57:25 -0400 Message-ID: <09c101c7aec6$9e44b8d0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7374777208BDC7449D5620EF9423256705397563@esealmw113.eemea.ericsson.se> Thread-Index: Acet9RUiumgJTZuuTMeNxUH+z/4DYAAADeeAADQgnyA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why would you think Emergency communications systems would not register? I think we have cross domain issues, but a UA in an ECS registers with a registrar in that ECS domain. The caller registers with a registrar in its domain. I don't see a problem with the proposed solution. I think it will work. Brian > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, June 13, 2007 4:03 PM > To: Ted Hardie; Jonathan Rosenberg; IETF SIP List > Subject: RE: [Sip] UA Loose Routing: Emergency example > > > Hi, > > >>This is not very relevant to the loose route solution as such, but > just > >>a small comment on the emergency service use-case. > >> > >>I am not sure whether the emergency service centers will always > >>register, and if they don't loose route of course does not solve the > >>problem. > >> > >>Regards, > >> > >>Christer > > > >Hi Christer, > > > >Can you expand on the issue here? I'm afraid I didn't understand it > from this message. > > As said in the draft, the loose route mechanism can only be used if the > UA has registered and indicated support of the loose route mechanism. > > So, entities that do not register will not be able to use the mechanism. > And, to my understanding the ESCs will not always register, which mean > it's not possible to use the loose route mechanism to forward the > initial request to them. > > Regards, > > Christer > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 17:36:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywzm-0003DZ-92; Thu, 14 Jun 2007 17:36:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hywzk-0002sV-33 for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 17:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywzj-0002op-Ls for sip@ietf.org; Thu, 14 Jun 2007 17:36:43 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hywzg-0001uv-IF for sip@ietf.org; Thu, 14 Jun 2007 17:36:43 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 14 Jun 2007 14:36:40 -0700 X-IronPort-AV: i="4.16,422,1175497200"; d="scan'208"; a="19114511:sNHT39583952" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 22:36:38 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Thu, 14 Jun 2007 22:36:37 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> In-Reply-To: <200706141751.l5EHpjlo001812@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceurMexh6vID5ivS+KycqR4lTVHrgAFGPxQ References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2C41B98 A6 A762007F5 D 019E677"@GBNTHT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net><4671 7533.6080609 @cisco.com> <200706141751.l5EHpjlo001812@dragon.ariadne.com> From: "Gilad Shaham" To: "Paul Kyzivat" X-OriginalArrivalTime: 14 Jun 2007 21:36:38.0266 (UTC) FILETIME=[16D04DA0:01C7AECC] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: sip@ietf.org, "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I never said that I endorse it... Neither am I saying that INFO is implicit NOTIFY. I'm saying INFO's functionality is notification on INVITE dialog usage without subscription. I agree it's an odd way to look at it (hence my comment on stupidity), but here is the analogy (bear with me): Suppose an implementation requires information during the lifetime of the INVITE dialog, something related to the call itself. The normal way of doing this is implementing an event package, something that holds the call-id, remote-tag and local-tag of the INVITE dialog to which it references. One could say that this is a lot of work, why not send the information on the INVITE dialog itself? Hence INFO roles into the game. It _does_ the same functionality from user's perspective. Implementers will find it much easier to do and it seems as a legitimate method for communicating this information. Of course it's not possible to say which INFO messages to receive as opposed to event notification which are specified in the subscription. Hence the implicit subscription (or lack of explicit subscription). Furthermore, as Dale pointer out, there is nothing similar to Event header, only the content-type tells what type of notification is this. I already said this is a problem with INFO, but some disagree and say that content-type is enough to hold the same information. That's at least my understanding of what's proposed here: KPML provides information on DTMF events that occur during the lifetime of the INVITE dialog. The events are sent in NOTIFY and the event package itself refers to the invite dialog with call-id, remote-tag and local-tag. One could say that the same information can be passed in INFO and it's easier to implement. No one subscribes to this information, somehow the subscription is implicit. If the logic of the analogy is correct, I think it has implications on INFO. > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Thursday, June 14, 2007 8:52 PM > To: sip@ietf.org > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > From: Paul Kyzivat >=20 > If you start down this path (I'd rather not), then rather than > considering INFO to be a notification of an implicit subscription you > might was well use NOTIFY for an implicit subscription. >=20 > In particular, NOTIFY is labeled with an event-type, so the recipient > knows whether or not it knows how to process the event. >=20 > Dale >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 17:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyx49-0005lq-GR; Thu, 14 Jun 2007 17:41:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyx48-0005ll-8Q for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 17:41:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyx47-0005ld-V4 for sip@ietf.org; Thu, 14 Jun 2007 17:41:15 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyx44-0002eq-L0 for sip@ietf.org; Thu, 14 Jun 2007 17:41:15 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5ELfBdK016792; Thu, 14 Jun 2007 16:41:11 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5ELf7a21392; Thu, 14 Jun 2007 16:41:07 -0500 (CDT) Message-ID: <4671B5F3.1050606@alcatel-lucent.com> Date: Thu, 14 Jun 2007 16:41:07 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Francois Audet , Dean Willis Subject: [Sip] draft-gurbani-sip-sipsec-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello: The notion of STARTTLS-like functionality in SIP has been mentioned on the list many times, in conjunction with end-to- end authentication that goes beyond the hob-by-hop model of sips. draft-gurbani-sip-sipsec-00 explored a possible way to accomplish this, without dvelving into too much of the details. The latest revision (-01) provides more details on the mechanism. A review of the draft and any comments would be much appreciated by the authors. Until it becomes available in the archives, you can get a copy from: https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.html Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 14 18:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxgt-0006m2-B7; Thu, 14 Jun 2007 18:21:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hyxgr-0006lu-FR for sip-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 18:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyxgr-0006lj-5N for sip@ietf.org; Thu, 14 Jun 2007 18:21:17 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyxgp-00017Z-NT for sip@ietf.org; Thu, 14 Jun 2007 18:21:17 -0400 Received: (qmail 14394 invoked by uid 0); 14 Jun 2007 22:20:53 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 14 Jun 2007 22:20:53 -0000 Message-ID: <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Vijay K. Gurbani" , "IETF SIP List" References: <4671B5F3.1050606@alcatel-lucent.com> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 Date: Fri, 15 Jun 2007 00:19:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, An initial comment: it seems wasteful to keep all proxies that are used to discover a path towards the UAS in the path of all signaling, acting as pass-throughs. Rather, there should be some mechanism to keep only the proxies that are needed to traverse NAT boundaries (e.g. those with an outbound flow towards the UAS) I imagine a two-phase approach: CONNECT as you have, let proxies that "know" they need to stay in Record-Route, then send a second CONNECT across the discovered Route Also, I would suggest to make CONNECT a well formed SIP request (possibly with dummy values). That would allow current proxies to participate in phase 1 of CONNECT without change (although they might Record-Route since CONNECT would be an unknown method - would need to strip such proxies from the discovered Route, e.g. by mandating a special tag to use for R-R for proxies that know what they're doing, removing all other entries) Regards, Jeroen Vijay K. Gurbani wrote: > Hello: The notion of STARTTLS-like functionality in SIP has been > mentioned on the list many times, in conjunction with end-to- > end authentication that goes beyond the hob-by-hop model of sips. > draft-gurbani-sip-sipsec-00 explored a possible way to accomplish > this, without dvelving into too much of the details. > > The latest revision (-01) provides more details on the mechanism. > A review of the draft and any comments would be much appreciated > by the authors. > > Until it becomes available in the archives, you can get a copy > from: > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.txt > https://svn.resiprocate.org/rep/ietf-drafts/gurbani/sip-sipsec/draft-gurbani-sip-sipsec-01.html > > Thank you. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 00:24:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3MC-0007id-Kj; Fri, 15 Jun 2007 00:24:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz3MB-0007eY-5E for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 00:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz3MA-0007eQ-Re for sip@ietf.org; Fri, 15 Jun 2007 00:24:18 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz3M9-0002LY-41 for sip@ietf.org; Fri, 15 Jun 2007 00:24:18 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5775621087; Fri, 15 Jun 2007 06:24:16 +0200 (CEST) X-AuditID: c1b4fb3e-af676bb0000007e1-de-4672147097d2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 277EE20006; Fri, 15 Jun 2007 06:24:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 06:24:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 06:24:14 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054DAA2D@esealmw113.eemea.ericsson.se> In-Reply-To: <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AceurMexh6vID5ivS+KycqR4lTVHrgAFGPxQABAYY4A= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2C41B98 A6 A762007F5 D 019E677"@GBNTHT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.n et><467 17533.608060 9@cisco.com> <200706141751.l5EHpjlo001812@dragon.ariadne.com> <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> From: "Christer Holmberg (JO/LMF)" To: "Gilad Shaham" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2007 04:24:15.0908 (UTC) FILETIME=[08B44E40:01C7AF05] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Gilad, I hear what you are saying, and if you really want to compary INFO to = implicit NOTIFY, you should also remember that in some cases INFO = messages will be sent in both directions, so doesn't that mean you would = have TWO subscriptions (one for each direction)? But, in order to avoid = unecessary discussions I agree with Paul that we shouldn't continue = onto that path :) =20 A couple of other comments, though: First, you say "Of course it's not possible to say which INFO messages = to receive". If you indicate which content types you support, you know = what you COULD receive in INFO (if someone sends you something you = haven't indicated support for it's a protocol error). Second, in an earlier mail you said that if we want to use INFO we = should still use the XML format as specified in KPML. The INFO = implementations I've seen do not use XML. E.g. Cisco seems to simply = send something like "Signal=3D 1 Duration=3D 160". I am not sure, but I = think there was a draft on that a long time ago. Personally I think't = it's a little "overkill" to send an XML body just in order to provide a = DTMF digit (and possibly additional duration information). But, as some = people say about SIP messages: size doesn't matter :) Regards, Christer > -----Original Message----- > From: Gilad Shaham [mailto:gshaham@juniper.net]=20 > Sent: 15. kes=E4kuuta 2007 0:37 > To: Paul Kyzivat > Cc: Dale.Worley@comcast.net; Christer Holmberg (JO/LMF); sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 > I never said that I endorse it... >=20 > Neither am I saying that INFO is implicit NOTIFY. I'm saying=20 > INFO's functionality is notification on INVITE dialog usage=20 > without subscription. >=20 > I agree it's an odd way to look at it (hence my comment on=20 > stupidity), but here is the analogy (bear with me): > Suppose an implementation requires information during the=20 > lifetime of the INVITE dialog, something related to the call=20 > itself. The normal way of doing this is implementing an event=20 > package, something that holds the call-id, remote-tag and=20 > local-tag of the INVITE dialog to which it references. > One could say that this is a lot of work, why not send the=20 > information on the INVITE dialog itself? Hence INFO roles=20 > into the game. > It _does_ the same functionality from user's perspective.=20 > Implementers will find it much easier to do and it seems as a=20 > legitimate method for communicating this information. >=20 > Of course it's not possible to say which INFO messages to=20 > receive as opposed to event notification which are specified=20 > in the subscription. > Hence the implicit subscription (or lack of explicit subscription). > Furthermore, as Dale pointer out, there is nothing similar to=20 > Event header, only the content-type tells what type of=20 > notification is this. I already said this is a problem with=20 > INFO, but some disagree and say that content-type is enough=20 > to hold the same information. >=20 > That's at least my understanding of what's proposed here: > KPML provides information on DTMF events that occur during=20 > the lifetime of the INVITE dialog. The events are sent in=20 > NOTIFY and the event package itself refers to the invite=20 > dialog with call-id, remote-tag and local-tag. One could say=20 > that the same information can be passed in INFO and it's=20 > easier to implement. No one subscribes to this information,=20 > somehow the subscription is implicit. >=20 > If the logic of the analogy is correct, I think it has=20 > implications on INFO. >=20 >=20 > > -----Original Message----- > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > Sent: Thursday, June 14, 2007 8:52 PM > > To: sip@ietf.org > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? > >=20 > > From: Paul Kyzivat > >=20 > > If you start down this path (I'd rather not), then rather than > > considering INFO to be a notification of an implicit subscription > you > > might was well use NOTIFY for an implicit subscription. > >=20 > > In particular, NOTIFY is labeled with an event-type, so the=20 > recipient=20 > > knows whether or not it knows how to process the event. > >=20 > > Dale > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 01:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4S2-0002ry-Nt; Fri, 15 Jun 2007 01:34:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz4S1-0002mM-NI for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 01:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4S0-0002ko-W3 for sip@ietf.org; Fri, 15 Jun 2007 01:34:25 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4S0-0008S2-EI for sip@ietf.org; Fri, 15 Jun 2007 01:34:24 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 14 Jun 2007 22:34:24 -0700 X-IronPort-AV: i="4.16,422,1175497200"; d="scan'208"; a="19253750:sNHT46181080" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jun 2007 06:34:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Fri, 15 Jun 2007 06:34:20 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A5395E@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF94232567054DAA2D@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AceurMexh6vID5ivS+KycqR4lTVHrgAFGPxQABAYY4AAAQFYEA== References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2C41B98 A6 A762007F5 D 019E677"@GBNTHT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.n et><46 717533.60806 09@cisco.com> <200706141751.l5EHpjlo001812@dragon.ariadne.com> <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> <7374777208BDC7449D5620EF94232567054DAA2D@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2007 05:34:22.0594 (UTC) FILETIME=[D415A620:01C7AF0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Christer, See inline. Thanks, Gilad > -----Original Message----- > From: Christer Holmberg (JO/LMF) = [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 15, 2007 7:24 AM > To: Gilad Shaham; Paul Kyzivat > Cc: Dale.Worley@comcast.net; sip@ietf.org > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? >=20 >=20 > Hi Gilad, >=20 > I hear what you are saying, and if you really want to compary INFO to > implicit NOTIFY, you should also remember that in some cases INFO = messages > will be sent in both directions, so doesn't that mean you would have = TWO > subscriptions (one for each direction)? But, in order to avoid = unecessary > discussions I agree with Paul that we shouldn't continue onto that = path > :) I agree there are cases where there are 2 actual subscriptions. One = unfortunate implication of this implicit subscription. I don't think we should draft a proposal for implicit subscription - = certainly not. I fear we are already on that path. We went on that path = as soon as INFO was allowed. We just didn't say so, but effectively we = implemented this functionality. If I'm right then I cannot understand = how one can oppose implicit subscriptions and endorse extended usage of = INFO at the same time. If I'm wrong it means that there is some kind of = additional functionality of INFO which I missed. I prefer that someone would show me what's basically wrong with the = analogy or my conclusions instead of why implicit subscriptions are a = bad idea. >=20 > A couple of other comments, though: >=20 > First, you say "Of course it's not possible to say which INFO messages = to > receive". If you indicate which content types you support, you know = what > you COULD receive in INFO (if someone sends you something you haven't > indicated support for it's a protocol error). Yeah, it possible, same discussion as before regarding content-type and = info type applies. =20 >=20 > Second, in an earlier mail you said that if we want to use INFO we = should > still use the XML format as specified in KPML. The INFO = implementations > I've seen do not use XML. E.g. Cisco seems to simply send something = like > "Signal=3D 1 Duration=3D 160". I am not sure, but I think there was a = draft on > that a long time ago. Personally I think't it's a little "overkill" to > send an XML body just in order to provide a DTMF digit (and possibly > additional duration information). But, as some people say about SIP > messages: size doesn't matter :) >=20 I don't like the idea that multiple formats will be defined in RFCs for = the same functionality. Maybe it's just me, but I think that in this = case "the more that merrier" does not apply. > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: Gilad Shaham [mailto:gshaham@juniper.net] > > Sent: 15. kes=E4kuuta 2007 0:37 > > To: Paul Kyzivat > > Cc: Dale.Worley@comcast.net; Christer Holmberg (JO/LMF); = sip@ietf.org > > Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? > > > > I never said that I endorse it... > > > > Neither am I saying that INFO is implicit NOTIFY. I'm saying > > INFO's functionality is notification on INVITE dialog usage > > without subscription. > > > > I agree it's an odd way to look at it (hence my comment on > > stupidity), but here is the analogy (bear with me): > > Suppose an implementation requires information during the > > lifetime of the INVITE dialog, something related to the call > > itself. The normal way of doing this is implementing an event > > package, something that holds the call-id, remote-tag and > > local-tag of the INVITE dialog to which it references. > > One could say that this is a lot of work, why not send the > > information on the INVITE dialog itself? Hence INFO roles > > into the game. > > It _does_ the same functionality from user's perspective. > > Implementers will find it much easier to do and it seems as a > > legitimate method for communicating this information. > > > > Of course it's not possible to say which INFO messages to > > receive as opposed to event notification which are specified > > in the subscription. > > Hence the implicit subscription (or lack of explicit subscription). > > Furthermore, as Dale pointer out, there is nothing similar to > > Event header, only the content-type tells what type of > > notification is this. I already said this is a problem with > > INFO, but some disagree and say that content-type is enough > > to hold the same information. > > > > That's at least my understanding of what's proposed here: > > KPML provides information on DTMF events that occur during > > the lifetime of the INVITE dialog. The events are sent in > > NOTIFY and the event package itself refers to the invite > > dialog with call-id, remote-tag and local-tag. One could say > > that the same information can be passed in INFO and it's > > easier to implement. No one subscribes to this information, > > somehow the subscription is implicit. > > > > If the logic of the analogy is correct, I think it has > > implications on INFO. > > > > > > > -----Original Message----- > > > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > > > Sent: Thursday, June 14, 2007 8:52 PM > > > To: sip@ietf.org > > > Subject: Re: [Sip] INFO message belongs only to INVITE dialog = usage? > > > > > > From: Paul Kyzivat > > > > > > If you start down this path (I'd rather not), then rather than > > > considering INFO to be a notification of an implicit = subscription > > you > > > might was well use NOTIFY for an implicit subscription. > > > > > > In particular, NOTIFY is labeled with an event-type, so the > > recipient > > > knows whether or not it knows how to process the event. > > > > > > Dale > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 02:01:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4sT-0006Us-6G; Fri, 15 Jun 2007 02:01:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz4sR-0006Uj-U1 for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 02:01:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4sR-0006Ub-Gt for sip@ietf.org; Fri, 15 Jun 2007 02:01:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4sQ-0006La-6n for sip@ietf.org; Fri, 15 Jun 2007 02:01:43 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz4rw-0002FM-LC; Fri, 15 Jun 2007 01:01:12 -0500 Message-ID: <46722BD4.5040503@softarmor.com> Date: Fri, 15 Jun 2007 01:04:04 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: SIP IETF , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > And, if we define a DTMF mime-type, we should of course also say in > which SIP message it can be used etc. But, again, we should not specify > the applications that are going to use it. But MIME types aren't just defined for SIP. There's a whole slew of protocols that can use any of the thousands of definede MIM types for millions of different reasons. SIP is just one protocol among many. > On my GSM phone, however, I don't need to active DTMF. If I am asked to > give my PIN code, I simply press buttons and they are sent as DTMF > tones. But what happens when your GSM phone receives a JPEG image? How about when it receives a Symbian executable stored in a ZIP file? > IF there are missing parts in the negotiation mechanism, we need to fix > that. > > Something like: > > Accept: application/my-dtmf;method=INFO Well, we agree it's broken. We're just debating the mechanism, and whether it's worth fixing. You and I seem to think it's worth fixing, others would just rather say "If it hurts' don't do it!". > OR, in the draft defining the content type, we specify that content type > X can only be sent using this and that method. I belive we do the same > thing for SDP. Once again, content types are defined more broadly than SIP. > > But, so far we haven't been interested in looking into these issues. We > just say that using INFO is against the spirit of SIP, it causes all > kind of problems etc etc. Not at all. I've said we need a registry of usage contexts that defines what specific content types and dispositions mean within that context usage. Lacking that, the safe thing is not to use INFO. I think Paul has said exactly the same thing, and that's pretty much what Jonathan has said -- although I think Jonathan is leaning more towards the "since defining these usages is hard, let's not use INFO" 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 sip-bounces@ietf.org Fri Jun 15 02:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4wy-0007Re-8q; Fri, 15 Jun 2007 02:06:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz4wx-0007PS-1b for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 02:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4ww-0007PH-OC for sip@ietf.org; Fri, 15 Jun 2007 02:06:22 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4wv-0006oW-HJ for sip@ietf.org; Fri, 15 Jun 2007 02:06:22 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz4wP-0002Fq-AV; Fri, 15 Jun 2007 01:05:49 -0500 Message-ID: <46722CE7.3060109@softarmor.com> Date: Fri, 15 Jun 2007 01:08:39 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Gilad Shaham Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2 C41B98 A6 A762007F5 D 019E677"@GBN THT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se> <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP IETF , "Elwell, John" , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gilad Shaham wrote: > It sounds to me as if you are saying something equivalent to the > following: INFO is a notification for some type of implicit > subscription on an INVITE dialog. (geez, I hope my interpretation > doesn't sound stupid) > . . . > Only thing part I feel is missing is actually stating which > "subscriptions" the UAs want to receive/support and the previous > discussion on content-type vs. another header to indicate the purpose > of the INFO message. I agree quite completely on this interpretation of the problem with INFO. -- 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 sip-bounces@ietf.org Fri Jun 15 03:19:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz65A-0004ar-Ub; Fri, 15 Jun 2007 03:18:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz659-0004ZB-89 for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 03:18:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz655-0004Xw-Kg for sip@ietf.org; Fri, 15 Jun 2007 03:18:51 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz653-0004tO-U3 for sip@ietf.org; Fri, 15 Jun 2007 03:18:51 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8949C209D1; Fri, 15 Jun 2007 09:18:48 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-42-46723d58038c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5AF6C20762; Fri, 15 Jun 2007 09:18:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:18:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UA Loose Routing: Emergency example Date: Fri, 15 Jun 2007 09:18:43 +0200 Message-ID: <7374777208BDC7449D5620EF94232567054DAE0B@esealmw113.eemea.ericsson.se> In-Reply-To: <09c101c7aec6$9e44b8d0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] UA Loose Routing: Emergency example thread-index: Acet9RUiumgJTZuuTMeNxUH+z/4DYAAADeeAADQgnyAAFcTywA== References: <466F5E26.2000709@cisco.com><7374777208BDC7449D5620EF94232567052CED33@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397563@esealmw113.eemea.ericsson.se> <09c101c7aec6$9e44b8d0$9501a8c0@cis.neustar.com> From: "Christer Holmberg (JO/LMF)" To: "Brian Rosen" , "Ted Hardie" , "Jonathan Rosenberg" , "IETF SIP List" X-OriginalArrivalTime: 15 Jun 2007 07:18:47.0754 (UTC) FILETIME=[6A6932A0:01C7AF1D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >Why would you think Emergency communications systems would not register? My understanding is that in many countries they are connected more like network equipment than user equipment, so in those cases they may not always register. (And, of course, if the ECS is in the PSTN it won't register, since the MGC does not register.) But, I am not an expert on this, so maybe I'm wrong. But, it's not really relevant for the problem we are trying to solve, so we don't need to discuss it futher within that context. Regards, Christer >=20 > I think we have cross domain issues, but a UA in an ECS=20 > registers with a registrar in that ECS domain. The caller=20 > registers with a registrar in its domain. >=20 > I don't see a problem with the proposed solution. I think it=20 > will work. >=20 > Brian >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF)=20 > > [mailto:christer.holmberg@ericsson.com] > > Sent: Wednesday, June 13, 2007 4:03 PM > > To: Ted Hardie; Jonathan Rosenberg; IETF SIP List > > Subject: RE: [Sip] UA Loose Routing: Emergency example > >=20 > >=20 > > Hi, > >=20 > > >>This is not very relevant to the loose route solution as such, but > > just > > >>a small comment on the emergency service use-case. > > >> > > >>I am not sure whether the emergency service centers will always=20 > > >>register, and if they don't loose route of course does=20 > not solve the=20 > > >>problem. > > >> > > >>Regards, > > >> > > >>Christer > > > > > >Hi Christer, > > > > > >Can you expand on the issue here? I'm afraid I didn't=20 > understand it > > from this message. > >=20 > > As said in the draft, the loose route mechanism can only be used if=20 > > the UA has registered and indicated support of the loose=20 > route mechanism. > >=20 > > So, entities that do not register will not be able to use=20 > the mechanism. > > And, to my understanding the ESCs will not always register,=20 > which mean=20 > > it's not possible to use the loose route mechanism to forward the=20 > > initial request to them. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 05:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8aF-0005N4-H5; Fri, 15 Jun 2007 05:59:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz8aE-0005Mw-4c for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 05:59:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz8aD-0005Mk-Bj for sip@ietf.org; Fri, 15 Jun 2007 05:59:09 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz8aC-0007aw-Sz for sip@ietf.org; Fri, 15 Jun 2007 05:59:09 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F9wwLj013298 for ; Fri, 15 Jun 2007 12:59:07 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 12:58:51 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 12:58:51 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 12:58:51 +0300 Received: from [172.21.40.65] (esdhcp04065.research.nokia.com [172.21.40.65]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F9wnuf029552; Fri, 15 Jun 2007 12:58:49 +0300 Message-ID: <467262D9.9020606@nokia.com> Date: Fri, 15 Jun 2007 12:58:49 +0300 From: Aki Niemi User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: ext Martin Hynar References: <1181734355.6595.18.camel@ww003517.tieto.eu.com> In-Reply-To: <1181734355.6595.18.camel@ww003517.tieto.eu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 09:58:51.0290 (UTC) FILETIME=[C6907FA0:01C7AF33] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: sip@ietf.org Subject: [Sip] Re: Several notes to entity-tags for SIP Events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Inline. ext Martin Hynar wrote: > Hello, > > I read through the draft sip-subnot-etags-00 and I found several issues > that needs to be clarified. > > 1. typo in introduction > In sentence "Typically, a SUBSCRIBE request is issued whenever a > subscription is installed, periodically refreshed or terminated." shall > be probably "NOTIFY". No, it really means SUBSCRIBE, but I think it's a little confusing. Perhaps: Typically, a SUBSCRIBE request is issued by the subscriber whenever it needs a subscription to be installed, periodically refreshed or terminated. > 2. some kind of misleading in text when talking about SIP PUBLISH > message as an example of entity tags usage. When talking about PUBLISH I > think, there is slightly different usage scenario. In response to > initial PUBLISH message, server generates entity tag. Client is mandated > to use this entity tag if she wants to change state of that particular > presence source. If this entity tag is not used, PUBLISH message > installs new presence source and not overwrites the former state. For > purposes of presence notifications, these publications are then > composed. This usage is a bit different that supposed for SUBSCRIBE > messages, The text evokes feeling of something different. Yes, the details in PUBLISH are a bit different. Do you have better wording in mind? > 3. What is exactly meant with "Meta-information-check"? What is this > meta information. Entity-tag for one. Added: ...meta-information related to a resource, e.g., its current entity-tag value. > 4. Besides RLS subscriptions there is one more problem, the > subscriptions to changes in documents. So extend the problem also on > notification about changes in multiple documents. Don't understand what you mean by "multiple documents". What use-case do you have in mind? > 5. In my mind, there popped up an idea to move the SIP-Etag into the > response to SUBSCRIBE message. This way client can be informed about the > entity tag also without sending the NOTIFY message at all. Have you > considered this possibility? Yes, this was considered, but rejected as there is currently no use for it in the 2xx. The way the "Suppress-Notify-If-Match" condition works is that a) the etag is the same and a 204 response is generated and b) the etag has changed and a NOTIFY is generated, which includes the new etag in SIP-ETag. > 6. What about situation when e.g. presentity has no presence document > installed and some body subscribes her. The the notifier sends empty > document, wouldn't be there some special handling? E.g. no entity tag. There is nothing specific to subnot-etags in this case. The server basically has two choices. Either it generates an etag for the empty document, and as a publication is received, changes that etag to a new value; or the server treats the empty document as some sort of floor value, gives it a constant etag value, in which case a subscriber that fetched an empty document once, would never get an update in case it happened to fetch again when there was no active publication. Either option is completely an implementation detail. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 07:16:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz9mn-0000Rc-3b; Fri, 15 Jun 2007 07:16:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Hz9mm-0000RX-5c for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 07:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz9ml-0000RO-Oj for sip@ietf.org; Fri, 15 Jun 2007 07:16:11 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz9ml-0003pa-2k for sip@ietf.org; Fri, 15 Jun 2007 07:16:11 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FBFnHd018520; Fri, 15 Jun 2007 14:16:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:16:04 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:16:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Date: Fri, 15 Jun 2007 14:16:03 +0300 Message-ID: In-Reply-To: <466FFD5A.2040005@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: AcetxiWj3uuBWRurRSen6dSh+xIEmgBeBm4g References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> <466FFD5A.2040005@bell-labs.com> From: To: X-OriginalArrivalTime: 15 Jun 2007 11:16:03.0786 (UTC) FILETIME=[8FBF4AA0:01C7AF3E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 >-----Original Message----- >From: ext Volker Hilt [mailto:volkerh@bell-labs.com]=20 >Sent: 13.06.2007 17:21 >To: Veikkolainen Simo (NSN - FI/Helsinki) >Cc: sip@ietf.org >Subject: Re: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 > >simo.veikkolainen@nsn.com wrote: >> Hi, >> I have a couple of comments/questions on this draft. >>=20 >> 3.2 Policy subscription >> The MIME type defined in this draft for session-independent policies=20 >> is application/session-policy+xml. It is mentioned that "a UA=20 >> compliant to this specification MUST support the User Agent Profile=20 >> Data Set for Media Policy", which (version -04) seems to define MIME=20 >> type application/media-policy-dataset+xml. I guess the MIME types=20 >> should be the same? >>=20 >Good catch. I'll change the MIME type in the framework to=20 >application/media-policy-dataset+xml. > >> 4.2 Overview, last sentence >> It is said that "Both types of policies [applying to the offer, or=20 >> both to the offer and answer] are supported by=20 >session-specific policy=20 >> mechanism." Does this require a mechanism to indicate in the policy=20 >> whether the policy applies to offer, or both offer and answer? With=20 >> this kind of mechanism the endpoint would not have to=20 >request a policy=20 >> decision for the answer, if the policy applies only to the offer. >>=20 >Yes. The policy event package supports this. Ah, this would be the "local-only" event parameter, I guess? This is fine then. -Simo > >> 4.3.1 Offer in request, example on page 12 What should be the=20 >> behaviour if the policy check at the end (messaages 9 and=20 >10) indicate=20 >> that the policy was unacceptable? Should there be a re-INVITE or=20 >> UPDATE, possible triggering a similar policy checking again in the=20 >> remote end? Would it be better to always wait for the policy=20 >decision=20 >> before answering with the final response? >>=20 >I think it is unlikely that a policy server would decline a=20 >session at this point since it has accepted the offer earlier.=20 >If it does occur, the correct behavior for the UA would be to=20 >terminate the session by sending a BYE. I believe section=20 >4.4.6. covers this to some extend but maybe this needs to be=20 >made more explicit. > >Volker > > > > >>> -----Original Message----- >>> From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >>> Sent: 22.05.2007 01:06 >>> To: IETF SIP List >>> Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 >>> >>> (As WG chair) >>> >>> This is to announce a Working Group Last Call on >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-sip-session-poli >>> cy-framew >>> ork-01.txt >>> >>> The WGLC is for 3 weeks and will end on 11th June 2007. >>> >>> Please respond to the editor, and to the SIP mailing list with=20 >>> comments. >>> >>> This WGLC is being held in conjunction with the two related=20 >documents=20 >>> in the SIPPING group, see mail below: >>> >>> Regards >>> >>> Keith >>> >>> --------------------------------------------------------------- >>> --------- >>> ----------------------------- >>> >>> Hi all, >>> >>> This is to announce Working Group Last Call on the=20 >following documents: >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-po >>> licy-data >>> set-04.txt (Recently updated to address the merging issue=20 >discussed=20 >>> on the mailing list)=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-p >>> ackage-03 >>> .txt (Unchanged since prior to IETF-68) >>> >>> This WGLC will end on 11 June 2007. >>> >>> Since the WG has previously reviewed these documents, the=20 >plan is to=20 >>> keep the same set of reviewers that previously volunteered: >>> Bob Penfield, Shida Schubert, Flemming Andreasen, Roni Even=20 >>> However, anyone additional that would like to volunteer would be=20 >>> appreciated to get a fresh set of eyes on the document. >>> >>> Feedback should be sent to the authors' email addresses (which is=20 >>> cc'ed using the tools alias in the above for your >>> convenience) and please copy the SIPPING mailing list. =20 >>> >>> Note: the original plan was to WGLC this set of documents=20 >along with=20 >>> the framework document that moved to SIP. So, stay tuned for an=20 >>> announcement on the SIP list of the WGLC plans for that document. >>> >>> Thanks, >>> Mary >>> SIPPING 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=20 >>> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >>> sipping@ietf.org for new developments on the application of sip >>> >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol Use=20 >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 >> sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 07:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzA4E-0002Wa-DF; Fri, 15 Jun 2007 07:34:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzA4C-0002WG-6V for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 07:34:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzA4B-0002W8-SV for sip@ietf.org; Fri, 15 Jun 2007 07:34:11 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzA4B-00011x-9h for sip@ietf.org; Fri, 15 Jun 2007 07:34:11 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B627C20799; Fri, 15 Jun 2007 13:34:10 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-2c-46727932c130 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9D7DF20516; Fri, 15 Jun 2007 13:34:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 13:34:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 13:29:17 +0200 Message-ID: <7374777208BDC7449D5620EF942325670556D12E@esealmw113.eemea.ericsson.se> In-Reply-To: <46722BD4.5040503@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcevEqWVVscmXZcfTXajugo6LBhE9wADuAiA References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> From: "Christer Holmberg (JO/LMF)" To: "Dean Willis" X-OriginalArrivalTime: 15 Jun 2007 11:34:10.0436 (UTC) FILETIME=[1770EC40:01C7AF41] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: SIP IETF , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>And, if we define a DTMF mime-type, we should of course also say in=20 >>which SIP message it can be used etc. But, again, we should not=20 >>specify the applications that are going to use it. >=20 >But MIME types aren't just defined for SIP. There's a whole=20 >slew of protocols that can use any of the thousands of=20 >definede MIM types for millions of different reasons. SIP is=20 >just one protocol among many. I don't think we need to say very much about different content types themselves. Because, again, the transport data itself is not directly related to the SIP session, but to the application above. I think we should focus more on whether we need some generic rules when sending application data over SIP, e.g. Whether some content disposition values are not allowed etc. >>On my GSM phone, however, I don't need to active DTMF. If I am asked=20 >>to give my PIN code, I simply press buttons and they are sent as DTMF=20 >>tones. >=20 >But what happens when your GSM phone receives a JPEG image?=20 >How about when it receives a Symbian executable stored in a ZIP file? I don't know - I've only had my phone for a few months, so I'm still in the how-to-use-the-phone-book stage :).=20 But, in any case, I think that is a question for the people implementing the phone applications, and not for the people specifying the protocol used to transport the image. >>IF there are missing parts in the negotiation mechanism, we need to fix that. >>=20 >>Something like: >>=20 >>Accept: application/my-dtmf;method=3DINFO >=20 >Well, we agree it's broken. We're just debating the=20 >mechanism, and whether it's worth fixing. You and I seem to=20 >think it's worth fixing, others would just rather say "If it=20 >hurts' don't do it!". If something needs to be fixed, I definately think we should do it. =20 >>OR, in the draft defining the content type, we specify that content=20 >>type X can only be sent using this and that method. I belive we do the >>same thing for SDP. >=20 >Once again, content types are defined more broadly than SIP. >=20 >>=20 >>But, so far we haven't been interested in looking into these issues.=20 >>We just say that using INFO is against the spirit of SIP, it causes=20 >>all kind of problems etc etc. >=20 >Not at all. I've said we need a registry of usage contexts=20 >that defines what specific content types and dispositions=20 >mean within that context usage. Lacking that, the safe thing=20 >is not to use INFO. I think Paul has said exactly the same=20 >thing, and that's pretty much what Jonathan has said --=20 >although I think Jonathan is leaning more towards the "since=20 >defining these usages is hard, let's not use INFO" model. That's probably because people have different opinions about what needs to be defined and registered. I still think that we do NOT need to register how the applications work and what they are actually going to do with the application data sent/received over SIP. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 08:24:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAqE-0004FX-5H; Fri, 15 Jun 2007 08:23:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzAqC-0004FE-BK for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 08:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAqC-0004F6-1o for sip@ietf.org; Fri, 15 Jun 2007 08:23:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAqB-0004L8-EH for sip@ietf.org; Fri, 15 Jun 2007 08:23:48 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2007 08:23:47 -0400 X-IronPort-AV: i="4.16,424,1175486400"; d="scan'208"; a="62838484:sNHT47886042" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5FCNlUt025998; Fri, 15 Jun 2007 08:23:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FCNUBi016303; Fri, 15 Jun 2007 12:23:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 08:23:30 -0400 Received: from [10.86.242.103] ([10.86.242.103]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 08:23:29 -0400 Message-ID: <467284C0.8090908@cisco.com> Date: Fri, 15 Jun 2007 08:23:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> In-Reply-To: <46722BD4.5040503@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 12:23:29.0976 (UTC) FILETIME=[FB76E380:01C7AF47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1319; t=1181910227; x=1182774227; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20Dean=20Willis=20; bh=FHW2NXY/g9Ov1ix1RyXE54AjcSqRd1gafMB16617P0w=; b=GCatiMEg62Kb2VW0rvX/wJ78vNQjnX4gPBqW6WcWQ14690fPVs0ccjU15f1c6MoCtPAx7bRe eZ/HwvJ5LvQmd15kDiuulGm9DLFa4K2ngnjM/7Z+GOJJA7bBE9hqko1H; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: SIP IETF , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: >> But, so far we haven't been interested in looking into these issues. We >> just say that using INFO is against the spirit of SIP, it causes all >> kind of problems etc etc. > > Not at all. I've said we need a registry of usage contexts that defines > what specific content types and dispositions mean within that context > usage. Lacking that, the safe thing is not to use INFO. I think Paul has > said exactly the same thing, and that's pretty much what Jonathan has > said -- although I think Jonathan is leaning more towards the "since > defining these usages is hard, let's not use INFO" model. I'm a little closer to the Jonathan position. I don't necessarily object to clarifying the use of INFO for some purpose, if that is the best way to do something. But in the case of DTMF work was already done. INFO was proposed and rejected in favor of SUB/NOT. Somebody has to make a case that the existing solution isn't good enough, and that another one is needed. Now I know that INFO is in use out there, by products of my own company among others. Those are *legacy* things. AFAIK they were done before the KPML solution was devised. We don't necessarily standardize them just because they are out there. People will implement them as needed. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 09:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCDx-0005rR-2Y; Fri, 15 Jun 2007 09:52:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzCDu-0005r7-UH for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 09:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCDu-0005qz-Kl for sip@ietf.org; Fri, 15 Jun 2007 09:52:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCDt-0000e3-Vc for sip@ietf.org; Fri, 15 Jun 2007 09:52:22 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4665220466; Fri, 15 Jun 2007 15:52:21 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-02-467299959d72 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2D636207B2; Fri, 15 Jun 2007 15:52:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 15:52:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 15:52:19 +0200 Message-ID: <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> In-Reply-To: <467284C0.8090908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcevSAvWdOX3GV2TSQWwF5z05B+QOgAAsk7A References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 15 Jun 2007 13:52:20.0848 (UTC) FILETIME=[64E96700:01C7AF54] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>>But, so far we haven't been interested in looking into these issues.=20 >>>We just say that using INFO is against the spirit of SIP,=20 >>>it causes all kind of problems etc etc. >>=20 >>Not at all. I've said we need a registry of usage contexts that=20 >>defines what specific content types and dispositions mean within that=20 >>context usage. Lacking that, the safe thing is not to use INFO. I=20 >>think Paul has said exactly the same thing, and that's pretty much=20 >>what Jonathan has said -- although I think Jonathan is leaning more=20 >>towards the "since defining these usages is hard, let's not=20 >>use INFO" model. >=20 >I'm a little closer to the Jonathan position. I don't=20 >necessarily object to clarifying the use of INFO for some=20 >purpose, if that is the best way to do something. >=20 >But in the case of DTMF work was already done. INFO was=20 >proposed and rejected in favor of SUB/NOT. Somebody has to=20 >make a case that the existing solution isn't good enough, and=20 >that another one is needed. It really depends on what you mean by "good enough". It's not always the technically best solution that "wins".=20 Thanks to the porn industry VHS "won" over Betamax, eventhough Betamax was supposed to be technically superior, and the SIP industry seems to (I don't have numbers to back that up, but it is the impression I have got) have chosen INFO over KPML :)=20 Whether it's because of compability issues, or because it's more simple to implement and deploy (it's not only about your local parser, but also issues related to having separate dialogs etc), or whether people don't think that DTMF sending fits the event subscription concept in the first place, or whether KPML simply was the right thing at the wrong time, I don't know. >Now I know that INFO is in use out there, by products of my=20 >own company among others. Those are *legacy* things. AFAIK=20 >they were done before the KPML solution was devised. We don't=20 >necessarily standardize them just because they are out there.=20 >People will implement them as needed. The problem is that it seems like the number of implementations is still growing. It's becoming a de facto standard. But, no matter what we do with DTMF, I still support the idea to look into whether we somehow clarify the generic usage of INFO. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 10:58:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDFp-0000o3-QH; Fri, 15 Jun 2007 10:58:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzDFo-0000nx-9m for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 10:58:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDFn-0000nD-Ua for sip@ietf.org; Fri, 15 Jun 2007 10:58:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDFm-0006sM-LG for sip@ietf.org; Fri, 15 Jun 2007 10:58:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2007 10:58:22 -0400 X-IronPort-AV: i="4.16,425,1175486400"; d="scan'208"; a="62852584:sNHT47706084" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5FEwMRR011558; Fri, 15 Jun 2007 10:58:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FEw2C0024897; Fri, 15 Jun 2007 14:58:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 10:58:10 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 10:58:10 -0400 Message-ID: <4672A900.70408@cisco.com> Date: Fri, 15 Jun 2007 10:58:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 14:58:10.0543 (UTC) FILETIME=[971D07F0:01C7AF5D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=585; t=1181919502; x=1182783502; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=0oZR1mWB7CxSm76PaPK9X48n1abbC2/6fYtOjQh0J0k=; b=o7XHH2tQat934xfsX3/LIoodCxhobGMB2qYByvU58Ka5ZWhocw2x2OYk8MLGvfOP93rYL4Ep vV3HKMV8K67EK4vsIVa2ThUIfGtSBWkwxXKtSMQf5a9FtinVtg9Q3tdG; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > But, no matter what we do with DTMF, I still support the idea to look > into whether we somehow clarify the generic usage of INFO. There is a big difference between specific additional uses, defined on a one-by-one basis, and *generic* usage. I don't know how to view generic usage as anything but an explicit move to support SIP as a tunneling protocol. And I think that is something that many people here *don't* want it to become. Opening it that way would pose many of the same issues that the Service-ID did. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 11:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDbU-0005ad-KL; Fri, 15 Jun 2007 11:20:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzDbT-0005a3-MO for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 11:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDWG-0004Bu-3t for sip@ietf.org; Fri, 15 Jun 2007 11:15:24 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDRL-0001Ke-P0 for sip@ietf.org; Fri, 15 Jun 2007 11:10:21 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l5FFA83x024690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2007 10:10:10 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se><25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com><7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se><7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se><46707F86.6060901@cisco.com> A<7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E66E@GBNTHT12009MSX.gb002.siemens.net>A<7374777208BDC7449D5620EF942325670541713F@esealmw113.eemea.ericsson.se><"0D5F89FAC29E 2C41B98 A6 A762007F5 D 019E677"@GBNTHT12009MSX.gb002.siemens.net> A<7374777208BDC7449D5620EF942325670541725F@esealmw113.eemea.ericsson.se><0D5F89FAC29E2C41B98A6A762007F5D019E6B8@GBNTHT12009MSX.gb002.siemens.net> <7374777208BDC7449D5620EF94232567054178FB@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE092090A538FF@EMAILEMEA3.jnpr.! net><4671 7533.6080609 @cisco.com> <200706141751.l5EHpjlo001812@dragon.ariadne.com> <0E48B768805E4D44A70709C8AE092090A5395C@EMAILEMEA3.jnpr.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <991D6293-26E5-444A-A954-315AE8963036@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 12:10:07 -0300 To: "Gilad Shaham" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sip@ietf.org, Paul Kyzivat , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I see what Gilad is saying and think its a useful way to think about the space (at least when SIP-T like problems are trying to use INFO). (and that does not mean I like it or that I think we should promote anything like implicit subscriptions going forward - quite the opposite) Mostly, it gives us a good place to look for how we recommend we solve those particular problems. Thanks for sharing that insight Gilad! RjS On Jun 14, 2007, at 6:36 PM, Gilad Shaham wrote: > I never said that I endorse it... > > Neither am I saying that INFO is implicit NOTIFY. I'm saying INFO's > functionality is notification on INVITE dialog usage without > subscription. > > I agree it's an odd way to look at it (hence my comment on stupidity), > but here is the analogy (bear with me): > Suppose an implementation requires information during the lifetime of > the INVITE dialog, something related to the call itself. The normal > way > of doing this is implementing an event package, something that > holds the > call-id, remote-tag and local-tag of the INVITE dialog to which it > references. > One could say that this is a lot of work, why not send the information > on the INVITE dialog itself? Hence INFO roles into the game. > It _does_ the same functionality from user's perspective. Implementers > will find it much easier to do and it seems as a legitimate method for > communicating this information. > > Of course it's not possible to say which INFO messages to receive as > opposed to event notification which are specified in the subscription. > Hence the implicit subscription (or lack of explicit subscription). > Furthermore, as Dale pointer out, there is nothing similar to Event > header, only the content-type tells what type of notification is > this. I > already said this is a problem with INFO, but some disagree and say > that > content-type is enough to hold the same information. > > That's at least my understanding of what's proposed here: > KPML provides information on DTMF events that occur during the > lifetime > of the INVITE dialog. The events are sent in NOTIFY and the event > package itself refers to the invite dialog with call-id, remote-tag > and > local-tag. One could say that the same information can be passed in > INFO > and it's easier to implement. No one subscribes to this information, > somehow the subscription is implicit. > > If the logic of the analogy is correct, I think it has implications on > INFO. > > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Thursday, June 14, 2007 8:52 PM >> To: sip@ietf.org >> Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? >> >> From: Paul Kyzivat >> >> If you start down this path (I'd rather not), then rather than >> considering INFO to be a notification of an implicit subscription > you >> might was well use NOTIFY for an implicit subscription. >> >> In particular, NOTIFY is labeled with an event-type, so the recipient >> knows whether or not it knows how to process the event. >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 12:14:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzERX-0001sd-6M; Fri, 15 Jun 2007 12:14:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzERV-0001sY-Jb for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 12:14:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzERV-0001sQ-9u for sip@ietf.org; Fri, 15 Jun 2007 12:14:33 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzERT-0004HH-To for sip@ietf.org; Fri, 15 Jun 2007 12:14:33 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5FGERfk010018; Fri, 15 Jun 2007 11:14:27 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5FGELa21211; Fri, 15 Jun 2007 11:14:21 -0500 (CDT) Message-ID: <4672BADD.3090008@alcatel-lucent.com> Date: Fri, 15 Jun 2007 11:14:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> In-Reply-To: <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > Vijay, Jeroen: Thanks for reading the draft. More inline. > An initial comment: it seems wasteful to keep all proxies that are > used to discover a path towards the UAS in the path of all signaling, > acting as pass-throughs. Rather, there should be some mechanism to > keep only the proxies that are needed to traverse NAT boundaries > (e.g. those with an outbound flow towards the UAS) I imagine a > two-phase approach: CONNECT as you have, let proxies that "know" they > need to stay in Record-Route, then send a second CONNECT across the > discovered Route That could be an optimization to consider. As I see it, there are three network topologies where this would be useful: 1) IETF rfc3261-type ecosystems: I suspect that here we'll have two, at most three proxies in such ecosystems; so such an optimization can be avoided. 2) IMS-type ecosystems: Given the high number of intermediaries that will field a request, the optmization may be helpful here. 3) P2P-type ecosystems: If recursive routing is being used to reach the peer, the optimization may be helpful here as well. > Also, I would suggest to make CONNECT a well formed SIP request > (possibly with dummy values). The current draft does not limit the headers that can appear in a CONNECT request. From intermediary transaction idenitification point of view, only a Via is needed. Dialog usage that requires To, From and Call-ID is an endpoint function, and in this case, the endpoint has other means to establish that dialog (i.e., set up the TLS tunnel and then send a dialog-establishing request over it.) > That would allow current proxies to participate in phase 1 of CONNECT > without change (although they might Record-Route since CONNECT would > be an unknown method - would need to strip such proxies from the > discovered Route, e.g. by mandating a special tag to use for R-R for > proxies that know what they're doing, removing all other entries) Would not the current option tag suffice? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 13:44:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFqO-0002GY-KK; Fri, 15 Jun 2007 13:44:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzFqM-0002GI-Ua for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 13:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFqM-0002G9-KO for sip@ietf.org; Fri, 15 Jun 2007 13:44:18 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFqL-0005z6-A4 for sip@ietf.org; Fri, 15 Jun 2007 13:44:18 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HzFqI-00038f-Or; Fri, 15 Jun 2007 12:44:15 -0500 In-Reply-To: <4672A900.70408@cisco.com> References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> <4672A900.70408@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 12:43:53 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: SIP IETF , "Christer Holmberg \(JO/LMF\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 15, 2007, at 9:58 AM, Paul Kyzivat wrote: > > There is a big difference between specific additional uses, defined > on a one-by-one basis, and *generic* usage. > > I don't know how to view generic usage as anything but an explicit > move to support SIP as a tunneling protocol. And I think that is > something that many people here *don't* want it to become. > > Opening it that way would pose many of the same issues that the > Service-ID did. > I'd argue we already used that can of worms for fishing when we did RFC 3265. Event packages provide a nice way of using SIP as a transport protocol, wrapped up with nice safety padding so one is less likely to hurt one's self using them and so that the application using the transported data is properly isolated from the SIP state machine. The real question is whether there's a real requirement to do the same thing for INFO. As has been pointed out, it's possible to do anything that you can do with INFO by doing a set of subscriptions (possibly MANY subscriptions) in parallel to an INVITE dialog usage. Especially since GRUU gives us a way to make the subscription endpoints the same as the INVITE endpoints. So we're just talking about efficiency here, not functionality. With what we've been talking about with INFO, it should be possible to declare support for many different INFO usages within a single INVITE dialog. This has the potential to make the INFO approach substantially more message-efficient than SUBSCRIBE/NOTIFY, which in most cases is going to require at least one subscription in each direction, and in some cases many subscriptions in each direction. The real question -- aside from the officially-sanctioned PSTN transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY THIS WG) DTMF are any applications being developed that need this sort of efficiency? My personal feeling is that if it is available, INFO will be used. Sometimes wisely, sometimes unwisely. But I can imagine myriad applications that could usefully accompany a multimedia session with little snippets of data being schlepped back and forth. I can also imagine doing the same thing with a parallel MSRP session. -- 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 sip-bounces@ietf.org Fri Jun 15 16:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzICW-00034V-Kd; Fri, 15 Jun 2007 16:15:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzICV-00033p-0l for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 16:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzICU-00033L-Gb for sip@ietf.org; Fri, 15 Jun 2007 16:15:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzICT-0002FA-0C for sip@ietf.org; Fri, 15 Jun 2007 16:15:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2007 16:15:16 -0400 X-IronPort-AV: i="4.16,426,1175486400"; d="scan'208"; a="123754697:sNHT420271094" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5FKFG1v008948; Fri, 15 Jun 2007 16:15:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5FKF65j017913; Fri, 15 Jun 2007 20:15:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 16:15:06 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 16:15:05 -0400 Message-ID: <4672F349.8000203@cisco.com> Date: Fri, 15 Jun 2007 16:15:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> In-Reply-To: <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 20:15:06.0168 (UTC) FILETIME=[DD4F2380:01C7AF89] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1439; t=1181938516; x=1182802516; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-gurbani-sip-sipsec-01 |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=1Um7+Wa9ADPDE2TMgX/l4XSPmyqEFKVNmmeDPxKvtNI=; b=H1EgVjFeDHK+SMV0c3lMFQ/6KJXxz6DMTtWPbtBQmD7ePfpgNvwppWSXUN4LUVAqm2GducSk pBUtITd86bFp0lwzzqJBEU5QwPezOx/IRwPb9WDBdyYW9/u44lPcK71p; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I like the direction this is headed. I have a few questions and observations: There seem to be some constraints for support of sipsec that I didn't see mentioned explicitly: - The UAC and each proxy must ensure that the transport used for the next hop is a connection-oriented, congestion-controlled transport. That is mentioned in the overview, but not specifically for the UAC and Proxy. - For the tunneling to work I don't think there can be shared use of the connection. That is something special here. (In case of SCTP, I guess it would be sufficient to reserve a stream.) There are some things that is is desirable to do that may be hard with sipsec, or at least need to be figured out. A couple that come to mind are: - best effort security - forking For best effort security, one option seems to be to delay the CONNECT until you know the capabilities of the callee. For instance, a session could be established with SIP or SIPS, including supported:sipsec. If the session is established, then it could be followed up with a CONNECT/Replaces. If you want to call an AOR that results in forking, CONNECT doesn't seem to work very well. I This may be a good reason to replace forking at a proxy with redirect. The proxy could return 3xx with the alternatives, which might be either SIP, SIPS, or SIPSEC. There are a lot of details to work our for this. Thanks, Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 17:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIts-0000bI-7b; Fri, 15 Jun 2007 17:00:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzItp-0000b7-7h for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzIto-0000az-UN for sip@ietf.org; Fri, 15 Jun 2007 17:00:04 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzIto-0003ra-7D for sip@ietf.org; Fri, 15 Jun 2007 17:00:04 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 818252086A; Fri, 15 Jun 2007 23:00:03 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-43-4672fdd3915f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5DC2720052; Fri, 15 Jun 2007 23:00:03 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 23:00:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 23:00:01 +0200 Message-ID: <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcevdMzhA7XZRz/iSDa54Pdws0t2wQAFdxZg References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> <4672A900.70408@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2007 21:00:03.0176 (UTC) FILETIME=[24D9E680:01C7AF90] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>There is a big difference between specific additional uses, defined on >>a one-by-one basis, and *generic* usage. >> >>I don't know how to view generic usage as anything but an explicit=20 >>move to support SIP as a tunneling protocol. And I think that is=20 >>something that many people here *don't* want it to become. >> >>Opening it that way would pose many of the same issues that the=20 >>Service-ID did. >> >=20 >I'd argue we already used that can of worms for fishing when we did =20 >RFC 3265. Event packages provide a nice way of using SIP as a =20 >transport protocol, wrapped up with nice safety padding so one is =20 >less likely to hurt one's self using them and so that the=20 >application using the transported data is properly isolated from the SIP state =20 >machine. >=20 >The real question is whether there's a real requirement to do the =20 >same thing for INFO. I think INFO pretty much already does the same thing. It is written that it shall not affect the SIP state. >As has been pointed out, it's possible to do anything that you can do =20 >with INFO by doing a set of subscriptions (possibly MANY =20 >subscriptions) in parallel to an INVITE dialog usage. Especially =20 >since GRUU gives us a way to make the subscription endpoints=20 >the same as the INVITE endpoints. >=20 >So we're just talking about efficiency here, not functionality. My understanding (maybe it's because of my background in H.248) of an subscribed event is that something somewhere triggers an event which I have requested to be informed about. In most cases I don't think that sending DTMFs between two SIP entities fits that concept. If two applications are exchaning data I don't understand why I, as the caller, have to tell the other party to send me a registration so that I can send him the data. The subscription is not used in order to be informed about detected events, but in order to be able to send data. BUT, if I e.g. control a media server using SIP, I could use an event registration to request to be informed about DTMFs detected on a media stream. In that case the DTMF may not be seen as data exchanged between two applications (and may not even be directly associated with another SIP dialog), but more as an indication. But, maybe that's more of a conceptual discussion than functional... >With what we've been talking about with INFO, it should be possible =20 >to declare support for many different INFO usages within a single =20 >INVITE dialog. This has the potential to make the INFO approach =20 >substantially more message-efficient than SUBSCRIBE/NOTIFY, which in =20 >most cases is going to require at least one subscription in each =20 >direction, and in some cases many subscriptions in each direction. Exactly - subscriptions which you MAY end up never using, but which in many cases still will consume SOME resources. >The real question -- aside from the officially-sanctioned PSTN =20 >transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY =20 >THIS WG) DTMF are any applications being developed that need this =20 >sort of efficiency? > >My personal feeling is that if it is available, INFO will be used. =20 >Sometimes wisely, sometimes unwisely. But I can imagine myriad =20 >applications that could usefully accompany a multimedia session with =20 >little snippets of data being schlepped back and forth. I can also =20 >imagine doing the same thing with a parallel MSRP session. I am sure all mechanisms we define have their pros and cons, and it's difficult for us to say that a specific application must use a specific mechanism etc. Our job is to define the tools for the application developers, and hopefully they will then be able to choose the most efficient tool, based on the characteristics, efficiency etc of the tools. And, I doubt anyone would use INFO for a real-time chat type of applications, with lots of relatively small messages, since it would overload intermediates. But, it's difficult for us to draw a clear line on what people can do and can't. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 17:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ3p-0002TP-FN; Fri, 15 Jun 2007 17:10:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzJ3n-0002TD-PW for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:10:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJ3n-0002T5-Fy for sip@ietf.org; Fri, 15 Jun 2007 17:10:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJ3m-0005Dl-3T for sip@ietf.org; Fri, 15 Jun 2007 17:10:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2007 17:10:22 -0400 X-IronPort-AV: i="4.16,426,1175486400"; d="scan'208"; a="62888989:sNHT44006478" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5FLAL8H031652; Fri, 15 Jun 2007 17:10:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FL7xBw002056; Fri, 15 Jun 2007 21:10:13 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 17:09:36 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 17:09:35 -0400 Message-ID: <4673000D.4040506@cisco.com> Date: Fri, 15 Jun 2007 17:09:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> <4672A900.70408@cisco.com> <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 21:09:35.0793 (UTC) FILETIME=[7A285210:01C7AF91] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=461; t=1181941821; x=1182805821; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20INFO=20message=20belongs=20only=20to=20INVITE =20dialog=20usage? |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=y93KFvl81fAoQ6kM+UZd3Zh5tjE8+wYx3NNu9z/RYVw=; b=L1ixQJ07u66mvLyIBPcT0saMO60u7xaXVlNKN/PuwO11ERjvF3ajWVGmjAASCgS21NqBX2zU pI2Z/Cm7S9vi1bQVuriATZraHSOoBWzU5cUuEDPIrMSv4/U0/fXHRL8g; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > And, I doubt anyone would use INFO for a real-time chat type of > applications, with lots of relatively small messages, since it would > overload intermediates. But, it's difficult for us to draw a clear line > on what people can do and can't. A large well known company with a colorful flag already uses MESSAGE within a dialog for this. The performance implications would be identical with INFO. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 17:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJbb-0001qa-5A; Fri, 15 Jun 2007 17:45:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzJbZ-0001qS-K1 for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJbZ-0001qK-AW for sip@ietf.org; Fri, 15 Jun 2007 17:45:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJbX-0003IY-MV for sip@ietf.org; Fri, 15 Jun 2007 17:45:17 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AB53120517; Fri, 15 Jun 2007 23:45:14 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-27-4673086a3c13 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A26EB2007B; Fri, 15 Jun 2007 23:45:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 23:45:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? Date: Fri, 15 Jun 2007 23:45:13 +0200 Message-ID: <7374777208BDC7449D5620EF942325670565DDF0@esealmw113.eemea.ericsson.se> In-Reply-To: <4673000D.4040506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? thread-index: AcevkZaQiNTSH55jR22QgwBriCeZcQABCFBg References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> <4672A900.70408@cisco.com> <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> <4673000D.404050 6@cisco. com> From: "Christer Holmberg (JO/LMF)" To: "Paul Kyzivat" X-OriginalArrivalTime: 15 Jun 2007 21:45:14.0416 (UTC) FILETIME=[74E04B00:01C7AF96] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP IETF , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>And, I doubt anyone would use INFO for a real-time chat type of=20 >>applications, with lots of relatively small messages, since=20 >>it would overload intermediates. But, it's difficult for us to draw a clear=20 >>line on what people can do and can't. >=20 >A large well known company with a colorful flag already uses=20 >MESSAGE within a dialog for this. The performance=20 >implications would be identical with INFO. Ok, so I guess someone WOULD use something similar for reat-time chat :) I don't remember what the MESSAGE RFC says about it. One question is: was MSRP available, and support deployed, when this company implemented it? Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 15 23:39:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzP7y-0003bJ-8Q; Fri, 15 Jun 2007 23:39:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzP7x-0003bE-Dc for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 23:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzP7x-0003b3-2k for sip@ietf.org; Fri, 15 Jun 2007 23:39:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzP7w-0002Z7-LJ for sip@ietf.org; Fri, 15 Jun 2007 23:39:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5G3ck813744 for ; Sat, 16 Jun 2007 03:38:46 GMT Date: Fri, 15 Jun 2007 22:35:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A137@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10D8D9AE@zrc2hxm0.corp.nortel.com> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sip-sips-04: 4XX instead of 3XX Thread-Index: AcepORQ113rve+TSQiWe2/BTJ135yQAColOAAQNrROAAnQAiwA== References: <012201c7a6fe$e9006650$0601a8c0@BEMBUSTER> <1ECE0EB50388174790F9694F77522CCF10BBDA0A@zrc2hxm0.corp.nortel.com> <093001c7a7b3$d21255b0$0601a8c0@BEMBUSTER> <46685ABD.7080101@cisco.com> <1ECE0EB50388174790F9694F77522CCF10C66502@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF10D8D9AE@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sip] draft-ietf-sip-sips-04: 4XX instead of 3XX X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm having some second toughts on the idea of defining new error responses for "SIPS Not Allowed" and "SIPS Not Supported" instead of 3XX. The rationale was the semantic was somewhat different, and that=20 it would avoid the problems of proxies that "automatically recurse on 3XX". However, now I'm thinking that 4XX may actually introduce a bigger problem. Because of HERFP, the new 4XX response codes are likely to be swalloed by proxies that do not support this specification. Which means the request will not be resent, causing a "hard failure" if no other branch responds. Using a 3XX on the other hand has a much greater chance of working through HERF since they tend to be forwarded. (Of course, they may suffer from the problem caused by proxies that are too keen on recursing). Comments? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 16 01:16:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzQdm-0004CB-HD; Sat, 16 Jun 2007 01:16:02 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzQdi-0003a4-05 for sip-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 01:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzQdg-0003FZ-Jh for sip@ietf.org; Sat, 16 Jun 2007 01:15:56 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzQdg-0002hJ-45 for sip@ietf.org; Sat, 16 Jun 2007 01:15:56 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 15 Jun 2007 22:15:55 -0700 X-IronPort-AV: i="4.16,428,1175497200"; d="scan'208"; a="19762837:sNHT45520516" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 16 Jun 2007 06:15:54 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage? X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Sat, 16 Jun 2007 06:15:50 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A53AF5@EMAILEMEA3.jnpr.net> In-Reply-To: <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO message belongs only to INVITE dialog usage? Thread-Index: AcevdMzhA7XZRz/iSDa54Pdws0t2wQAFdxZgAA/MVvA= References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FABF@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com><7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se><46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com><7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se><4672A900.70408@cisco.com> <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> From: "Gilad Shaham" To: "Christer Holmberg \(JO/LMF\)" , "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2007 05:15:54.0144 (UTC) FILETIME=[69CF5A00:01C7AFD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, See Inline Gilad Christer Holmberg wrote: > >As has been pointed out, it's possible to do anything that you can do > >with INFO by doing a set of subscriptions (possibly MANY > >subscriptions) in parallel to an INVITE dialog usage. Especially > >since GRUU gives us a way to make the subscription endpoints > >the same as the INVITE endpoints. > > > >So we're just talking about efficiency here, not functionality. >=20 > My understanding (maybe it's because of my background in H.248) of an > subscribed event is that something somewhere triggers an event which I > have requested to be informed about. >=20 > In most cases I don't think that sending DTMFs between two SIP entities > fits that concept. If two applications are exchaning data I don't > understand why I, as the caller, have to tell the other party to send me > a registration so that I can send him the data. The subscription is not > used in order to be informed about detected events, but in order to be > able to send data. You do not tell the other party to send registration so you can send him data. The other party asks for this data and you send it or vise versa. Some of us are saying that the lack of ability in SIP to state which INFO messages each ends wants to receive, it is a major drawback. As long as new RFCs don't focus on INFO, this problem is usually limited, but if we use INFO more broadly it's a real issue. >=20 > BUT, if I e.g. control a media server using SIP, I could use an event > registration to request to be informed about DTMFs detected on a media > stream. In that case the DTMF may not be seen as data exchanged between > two applications (and may not even be directly associated with another > SIP dialog), but more as an indication. >=20 > But, maybe that's more of a conceptual discussion than functional... >=20 I'm not sure I understand what you mean, but it sounds to me as if you are describing a solution to the issue of specifying which INFOs are required.=20 > >With what we've been talking about with INFO, it should be possible > >to declare support for many different INFO usages within a single > >INVITE dialog. This has the potential to make the INFO approach > >substantially more message-efficient than SUBSCRIBE/NOTIFY, which in > >most cases is going to require at least one subscription in each > >direction, and in some cases many subscriptions in each direction. >=20 > Exactly - subscriptions which you MAY end up never using, but which in > many cases still will consume SOME resources. >=20 And if it would have been possible to subscribe to many different event packages in a single message, would that be an equivalent solution? =20 > >The real question -- aside from the officially-sanctioned PSTN > >transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY > >THIS WG) DTMF are any applications being developed that need this > >sort of efficiency? > > > >My personal feeling is that if it is available, INFO will be used. > >Sometimes wisely, sometimes unwisely. But I can imagine myriad > >applications that could usefully accompany a multimedia session with > >little snippets of data being schlepped back and forth. I can also > >imagine doing the same thing with a parallel MSRP session. >=20 > I am sure all mechanisms we define have their pros and cons, and it's > difficult for us to say that a specific application must use a specific > mechanism etc. Our job is to define the tools for the application > developers, and hopefully they will then be able to choose the most > efficient tool, based on the characteristics, efficiency etc of the > tools. >=20 Right. Currently if extended usage of INFO is needed, it's not well defined and there are several problems to resolve. We might have been taking this conversation to the wrong direction. If some feel that SUBSCRIBE/NOTIFY might be too complex in some situations, I think we should discuss it outside the context of INFO. INFO is just one solution to this problem. If the best solution in this case would turn out to be INFO, we will be more motivated to fix its problems. I don't see a reason to "reverse engineer" a proprietary solution that some vendors took that involved INFO at the time. We need a problem definition. Whether or not the end solution will be similar to the vendor's solution is irrelevant. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 16 03:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzSsq-0002iK-Uc; Sat, 16 Jun 2007 03:39:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzSsp-0002iF-Dm for sip-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 03:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzSsp-0002i7-4B for sip@ietf.org; Sat, 16 Jun 2007 03:39:43 -0400 Received: from qb-out-0506.google.com ([72.14.204.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzSsl-00005Q-JL for sip@ietf.org; Sat, 16 Jun 2007 03:39:43 -0400 Received: by qb-out-0506.google.com with SMTP id a39so722105qbd for ; Sat, 16 Jun 2007 00:39:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=sRc88+OcxNpIaPuLUYiwnmHuSjoxs0RhG05RouzicCbiAn/9IipWvOQvfXVf51MMy98sPYDwUb48Vy/wUTgwVCYAGPlTCRwFV2mdG2JgZVBPO/FYwogRdljD1MXAzTzNGopyv1V3D7fOgHmzrEalwk7pmx/G7z+miolOt8l57dU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=LEW9tP7UnK8Dem3JyK/tEZEz+SXN6BxMCfGf0LOX4294/bMMR1c6aoLVpJWu7Rs0Q1HVin6+I5Cb26Z9DqNxwvyom+Cy9yj3rbzWEAoC4q4PJcCfwzdyRnasAfxxiV+K0ymsF+XyFhRoAFqbUjyNBBwNzsjmlQ2HIvAgelaBO+s= Received: by 10.114.106.1 with SMTP id e1mr3921564wac.1181979548798; Sat, 16 Jun 2007 00:39:08 -0700 (PDT) Received: from leo ( [125.115.171.66]) by mx.google.com with ESMTP id m26sm7306432pof.2007.06.16.00.39.05 (version=SSLv3 cipher=RC4-MD5); Sat, 16 Jun 2007 00:39:08 -0700 (PDT) Message-ID: <005101c7afe8$16c59730$1200a8c0@leo> From: "Leo Lv" To: Date: Sat, 16 Jun 2007 15:29:20 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] Sigcomp ASM Tool X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0611273889==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0611273889== Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C7B02B.1C1AF700" This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C7B02B.1C1AF700 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQp3ZSByZWxlYXNlZCBhIGZyZWUgc2lnbmFsIGNvbXByZXNzKFNpZ2NvbXApIGFz bSBjb21waWxlcihHVUkgd2FzIGJhc2VkIG9uIFdpbmRvd3MgQyMpLCB3aGljaCBjYW4gY29udmVy dCBzaWdjb21wIGFzbSBjb2RlIHRvIGJ5dGUgY29kZSB3aGljaCBpcyB1c2VkIGluIHRoZSBVRFZN LiBUaGUgZG93bmxvYWQgc2l0ZSBpcyBodHRwOi8vd3d3Lmp1cGhvb24uY29tL2VuL3N1cHBvcnQv ZG93bmxvYWRzJnVwZGF0ZXMuaHRtIC4NCg0KSWYgeW91IGhhdmUgYW55IHByb2JsZW0gd2hpbGUg dXNpbmcgQVNNIHRvb2wsIHBsZWFzZSBtYWlsIHRvIGJvYi5saXVAanVwaG9vbi5jb20NCg0KQmVz dCByZWdhcmRzLA0KDQpMZW8gTHY= ------=_NextPart_000_004C_01C7B02B.1C1AF700 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMwODYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaSBhbGwsPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+d2UgcmVsZWFzZWQgYSBmcmVlIHNpZ25hbCBjb21wcmVzcyhTaWdjb21wKSBhc20gY29t cGlsZXIoR1VJIA0Kd2FzIGJhc2VkIG9uIFdpbmRvd3MgQyMpLCB3aGljaCBjYW4gY29udmVydCBz aWdjb21wIGFzbSBjb2RlIHRvIGJ5dGUgY29kZSB3aGljaCANCmlzJm5ic3A7dXNlZCBpbiB0aGUg VURWTS4gVGhlIGRvd25sb2FkIHNpdGUgaXMgPEEgDQpocmVmPSJodHRwOi8vd3d3Lmp1cGhvb24u Y29tL2VuL3N1cHBvcnQvZG93bmxvYWRzJmFtcDt1cGRhdGVzLmh0bSI+aHR0cDovL3d3dy5qdXBo b29uLmNvbS9lbi9zdXBwb3J0L2Rvd25sb2FkcyZhbXA7dXBkYXRlcy5odG08L0E+Jm5ic3A7Ljwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPklmIHlvdSBoYXZlIGFueSBwcm9ibGVtIHdoaWxlIHVzaW5nIEFTTSB0b29s LCBwbGVhc2UgbWFpbCB0byANCjxBIGhyZWY9Im1haWx0bzpib2IubGl1QGp1cGhvb24uY29tIj5i b2IubGl1QGp1cGhvb24uY29tPC9BPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkJlc3QgcmVnYXJkcyw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5MZW8gTHY8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_004C_01C7B02B.1C1AF700-- --===============0611273889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0611273889==-- From sip-bounces@ietf.org Sat Jun 16 14:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzdAT-0006xq-HJ; Sat, 16 Jun 2007 14:38:37 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzdAS-0006xi-Ec for sip-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 14:38:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzdAS-0006xa-5C for sip@ietf.org; Sat, 16 Jun 2007 14:38:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzdAQ-0000dS-TR for sip@ietf.org; Sat, 16 Jun 2007 14:38:36 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1HzdAN-0005Av-PO; Sat, 16 Jun 2007 13:38:32 -0500 Message-ID: <46742ED8.6000806@softarmor.com> Date: Sat, 16 Jun 2007 13:41:28 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage? References: <0E48B768805E4D44A70709C8AE09209097E7E9@EMAILEMEA3.jnpr.net><0E48B768805E4D44A70709C8AE09209097EBA9@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FCFE@esealmw113.eemea.ericsson.se><0E48B768805E4D44A70709C8AE09209097EBD5@EMAILEMEA3.jnpr.net><7374777208BDC7449D5620EF942325670521FFE1@esealmw113.eemea.ericsson.se> <25F6B846-34F2-452B-88C9-E99817C654E1@softarmor.com> <7374777208BDC7449D5620EF94232567052CE4D4@esealmw113.eemea.ericsson.se> <7374777208BDC7449D5620EF9423256705397548@esealmw113.eemea.ericsson.se> <46707F86.6060901@cisco.com> <7374777208BDC7449D5620EF942325670541706A@esealmw113.eemea.ericsson.se> <46722BD4.5040503@softarmor.com> <467284C0.8090908@cisco.com> <7374777208BDC7449D5620EF942325670556D69F@esealmw113.eemea.ericsson.se> <4672A900.70408@cisco.com> <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF942325670565DDDA@esealmw113.eemea.ericsson.se> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: SIP IETF , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > And, I doubt anyone would use INFO for a real-time chat type of > applications, with lots of relatively small messages, since it would > overload intermediates. Well, personally, I might. I think that MESSAGE could well have been an INFO usage. Instead, we developed a protocol extension that confused what was happening at the SIP level (transport) with an application function (Presenting data to the user). It was bad design. Once all the proxies that don't have to be there for something like NAT traversal have dropped out, the only intermediaries being loaded are the ones that need to be loaded in order to make the communication work at all. When one brings in the performance gains of SIPSEC (proxies no longer parse, decrypt, or encrypt messages once a CONNECT completes), it's actually a pretty efficient approach. -- 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 sip-bounces@ietf.org Sat Jun 16 17:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzfab-0000V5-UY; Sat, 16 Jun 2007 17:13:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzfaZ-0000UI-EX for sip-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 17:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzfaZ-0000UA-4y for sip@ietf.org; Sat, 16 Jun 2007 17:13:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzfaX-0000wa-Rd for sip@ietf.org; Sat, 16 Jun 2007 17:13:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2007 17:13:42 -0400 X-IronPort-AV: i="4.16,430,1175486400"; d="scan'208"; a="62941339:sNHT43560688" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5GLDfHO013179 for ; Sat, 16 Jun 2007 17:13:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5GLDb5f007991 for ; Sat, 16 Jun 2007 21:13:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 17:13:36 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.157]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 17:13:36 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 16 Jun 2007 16:13:37 -0500 To: sip@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jun 2007 21:13:36.0822 (UTC) FILETIME=[343C2D60:01C7B05B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1405; t=1182028421; x=1182892421; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20New=20draft=20modifying=20RFC=204412=20for=20Responses |Sender:=20 |To:=20sip@ietf.org; bh=HMG8F3ZeLKTjabBfqaXSnx8tMOoZQbUb4Sau+MfKkLg=; b=Gh1GwvHe1mMIBNs/RGYKlUAHkM09KbHWFnUy+80KG0VxvnODPxKIjPHnIMOX/DpbGmXujQNu 4t0ZqGTIJn0gndygxBj74ViD/dPnfOb+myv2brndJmP2AxFh++BTHAzE; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Sip] New draft modifying RFC 4412 for Responses X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org SIP WG Here is a new ID I've written because of implementation considerations to allow a SIP Resource-Priority header (RPH) in responses, which RFC 4412 currently disallows, assuming only that stateful devices will use RPH. There have been many requests to have this "only stateful devices" restriction relaxed, in certain scenarios. This ID does this, and proposes how IANA is changed accordingly wrt RPH. This ID does nothing else. Comments are appreciated. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Allowing SIP Resource Priority Header in > SIP Responses > Author(s) : J. Polk > Filename : draft-polk-sip-rph-in-responses-00.txt > Pages : 6 > Date : 2007-6-15 > > The Session Initiation Protocol (SIP) Resource Priority Header > (RPH), in its current form, is ignored in SIP responses. This was a > design choice during RFC 4412's development. This is now considered > a bad design choice in certain scenarios. This document corrects > RFC 4412's communications model by optionally allowing a SIP server > or user agent client to process the Resource-Priority Header in a > response. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-00.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 17 18:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02wM-0003QJ-My; Sun, 17 Jun 2007 18:09:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I02wL-0003QC-0H for sip-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 18:09:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02wK-0003Q4-N4 for sip@ietf.org; Sun, 17 Jun 2007 18:09:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I02wK-0003me-CC for sip@ietf.org; Sun, 17 Jun 2007 18:09:44 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I02wK-0007Kg-3m for sip@ietf.org; Sun, 17 Jun 2007 17:09:44 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: SIP IETF From: Dean Willis Date: Sun, 17 Jun 2007 17:09:28 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Sip] Forward on request: Be a NOMCOM Volunteer Today X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Lakshminath Dondeti To: IETF Announcement Date: June 4, 2007 Subject: Nomcom 2007-8: First Call for Volunteers Folks, If you have attended 3 out of the past 5 IETF meetings, you are eligible to serve on Nomcom 2007-2008. Please volunteer and you may become one of the voting members of the committee that selects about half of the members to the IESG and IAB and one IAOC member. RFC 3777 describes the process and the responsibilities in detail. Below is the list of people from the IESG, IAB and IAOC whose terms end during the March 2008 IETF meeting. IAOC: Ed Juskevicius IAB: Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman David Oran Eric Rescorla IESG: Lisa Dusseault -- Applications Area Director Jari Arkko -- Internet Area Director Dan Romascanu -- Operations and Management Area Director Cullen Jennings -- Real-time Applications and Infrastructure Area Director Ross Callon --- Routing Area Director Sam Hartman -- Security Area Director Magnus Westerlund -- Transport Area Director Before volunteering, please think about whether you want to be considered for one of those positions instead. If you are already convinced, please send an email before 12:00 noon ET (16:00 UTC/GMT) on July 5, 2007 (otherwise, please read on) To: ldondeti@qualcomm.com Subject: Nomcom 2007-8 Volunteer Body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/ Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 1-2 days stating whether you are qualified or not. If you don't receive anything, please re-send your email with the tag (duplicate) in the subject line. Not convinced yet? Please consider that nomcom members play an important role in shaping the leadership of the IETF. If you are a people person, you will enjoy meeting many of the active contributors to the IETF. If you prefer instead to read a lot of email, well, we have that too. Being a nomcom member is also an important responsibility: it requires adherence to confidentiality rules and some time commitment from the members. The term begins just prior to the Chicago meeting and we expect most of the work to be completed by January 2008. During this period, the nomcom members -- collect requirements from the community and interviews candidates during the Chicago and Vancouver IETF meetings -- review candidates' statements and weighs community feedback -- participate in candidate selection deliberations (weekly conferences calls) Nomcom members are selected following a publicly verifiable random selection method specified in RFC 3797. For the nomcom to work as it should, the pool from which the volunteers are chosen should be as large as possible. The more people who volunteer, the better chance we have of choosing a random yet representative cross section of the IETF population. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. So please volunteer! thanks, Lakshminath _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 17 19:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04ZP-0000pj-Mp; Sun, 17 Jun 2007 19:54:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I04ZO-0000pd-BS for sip-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 19:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04ZO-0000pV-1w for sip@ietf.org; Sun, 17 Jun 2007 19:54:10 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I04ZM-0003al-OD for sip@ietf.org; Sun, 17 Jun 2007 19:54:10 -0400 Received: from uk1lt10071.iptel.org (shell.iptel.org [213.192.59.74]) by mail.iptel.org (Postfix) with ESMTP id C73DB1811583; Mon, 18 Jun 2007 01:54:10 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Jun 2007 01:41:08 +0200 To: "DRAGE, Keith \(Keith\)" , "IETF SIP List" From: Jiri Kuthan Subject: Re: [Sip] draft-ietf-sip-saml-02 In-Reply-To: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.luce nt.com> References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20070617235410.C73DB1811583@mail.iptel.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: sisalem@iptel.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >- applicability - does it identify and solve a problem? I think it does. A specific case it simplifies is coordination of access control in federations. >- completeness - is there something missing? I'm personally missing scenarios which - use redirection as opposed to proxy mode. IMO, it is beneficial to have the AS operated in 3xx mode for better scalability. - use SAML-by-value, in addition to SAML-by-reference. I personally find the SAML-by-reference quite non-real-time and harder-to-scale too. Perhaps there are arguments why proxy+by/reference is the best thing, but if that's the case I think they should be mentioned in the document. Other things have been tracked but the debates are IMO not yet visible in the spec: - reference of the SAML document to some parts of the initial SIP request so that it is harder to replay SAML permisssions (issue #5) - backwards compatibility with Identity-info (#12) - the by-value scenarios is here actually too .. (#9) -jiri -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 17 22:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0709-0008NI-RM; Sun, 17 Jun 2007 22:29:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0708-0008NB-E9 for sip-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 22:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0708-0008N3-3o for sip@ietf.org; Sun, 17 Jun 2007 22:29:56 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0705-0000s7-Tb for sip@ietf.org; Sun, 17 Jun 2007 22:29:56 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc11) with ESMTP id <2007061802295301100ck77de>; Mon, 18 Jun 2007 02:29:53 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l5I2Tr8t008108 for ; Sun, 17 Jun 2007 22:29:53 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l5I2TqN0008104; Sun, 17 Jun 2007 22:29:52 -0400 Date: Sun, 17 Jun 2007 22:29:52 -0400 Message-Id: <200706180229.l5I2TqN0008104@dragon.ariadne.com> To: sip@ietf.org From: Dale.Worley@comcast.net In-reply-to: <466F5E26.2000709@cisco.com> (jdrosen@cisco.com) Subject: Re: [Sip] UA Loose Routing Issue #1: Backwards compatibility References: <466F5E26.2000709@cisco.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org From: Jonathan Rosenberg THe mechanism basically changes the way proxies handle requests. Instead of rewriting the request URI for out-of-dialog requests, they'll push a route header and leave the r-uri alone. This allows the original R-URI and any parameters it contains to get delivered to the UAS. Unfortunately, I have to say that I dislike this mechanism intensely, as it changes the whole philosophy of how SIP messages are routed. On a more practical level, it only deals with one level of address mapping, and it's not usable by a UA that doesn't implement the change -- whereas I would expect that the optimal mechanism is one that tweaks the behavior of the proxy doing the mapping, and requires no change from any other system. Dale _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqy-0002XU-Ih; Mon, 18 Jun 2007 02:36:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Aqw-0002Wg-Lu for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqw-0002WS-96 for sip@ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Aqu-0007R0-T7 for sip@ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6adEh010843 for ; Sun, 17 Jun 2007 23:36:39 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6ab9n017650 for ; Sun, 17 Jun 2007 23:36:38 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:37 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 13:48:33 +0900 From: Eric Burger To: Message-ID: Thread-Topic: INFO, from a reformed Abuser Thread-Index: AcexEBrEWZU+QB0DEdy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] INFO, from a reformed Abuser X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Who am I? My name is Eric. I have a problem. I am on the road to recovery... Yes, I am responsible for RFC 4722, which, as a side effect, instructs people on the THEN state-of-the-art (pre-SUB/NOT) of how to transport user stimulus that HAPPENS to be key presses on a key pad using INFO messages. As a side note, 90% of the time, we are really talking about real DTMF detection, extracted from G.711, at a media server. I am also responsible for RFC 4730, KPML, which instructs people on the CURRENT state-of-the-art of how to transport user stimulus using SUBSCRIBE and NOTIFY. Note the key [sic] phrase: "transport user stimulus." There were some suggestions to use RFC 2833 / 4733 to transport DTMF. I would offer, if your goal is to TRANSPORT IN-BAND TONES THAT HAPPEN TO BE DTMF, your ONE and ONLY ONE option is RFC 4733. You are *transporting* media; use a media transport protocol. If your goal is to TRANSPORT USER *SIGNALING*, your ONE and ONLY ONE option is RFC 4730, KPML. We have seen tons and tons of reasons why INFO is "bad." I would offer that INFO is simply underspecified. Namely, the remedy is to fix the "why am I getting this message and what am I supposed to do with it" question. Event: and Content-Type: do this for NOTIFY. A similar mechanism could be done for INFO (note the deliberate use of passive voice). Since we do not seem to have pressure to add those facilities to INFO, I would offer we get on with life. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If youFrom sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqy-0002XU-Ih; Mon, 18 Jun 2007 02:36:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Aqw-0002Wg-Lu for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqw-0002WS-96 for sip@ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Aqu-0007R0-T7 for sip@ietf.org; Mon, 18 Jun 2007 02:36:42 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6adEh010843 for ; Sun, 17 Jun 2007 23:36:39 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6ab9n017650 for ; Sun, 17 Jun 2007 23:36:38 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:37 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 13:48:33 +0900 From: Eric Burger To: Message-ID: Thread-Topic: INFO, from a reformed Abuser Thread-Index: AcexEBrEWZU+QB0DEdy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Sip] INFO, from a reformed Abuser X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Who am I? My name is Eric. I have a problem. I am on the road to recovery... Yes, I am responsible for RFC 4722, which, as a side effect, instructs people on the THEN state-of-the-art (pre-SUB/NOT) of how to transport user stimulus that HAPPENS to be key presses on a key pad using INFO messages. As a side note, 90% of the time, we are really talking about real DTMF detection, extracted from G.711, at a media server. I am also responsible for RFC 4730, KPML, which instructs people on the CURRENT state-of-the-art of how to transport user stimulus using SUBSCRIBE and NOTIFY. Note the key [sic] phrase: "transport user stimulus." There were some suggestions to use RFC 2833 / 4733 to transport DTMF. I would offer, if your goal is to TRANSPORT IN-BAND TONES THAT HAPPEN TO BE DTMF, your ONE and ONLY ONE option is RFC 4733. You are *transporting* media; use a media transport protocol. If your goal is to TRANSPORT USER *SIGNALING*, your ONE and ONLY ONE option is RFC 4730, KPML. We have seen tons and tons of reasons why INFO is "bad." I would offer that INFO is simply underspecified. Namely, the remedy is to fix the "why am I getting this message and what am I supposed to do with it" question. Event: and Content-Type: do this for NOTIFY. A similar mechanism could be done for INFO (note the deliberate use of passive voice). Since we do not seem to have pressure to add those facilities to INFO, I would offer we get on with life. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqz-0002Xe-8H; Mon, 18 Jun 2007 02:36:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Aqx-0002XN-Q0 for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqx-0002X7-Fc for sip@ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Aqw-0007R6-2Y for sip@ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6aemm010846 for ; Sun, 17 Jun 2007 23:36:40 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6ab9p017650 for ; Sun, 17 Jun 2007 23:36:39 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 18:19:35 +0900 From: Eric Burger To: Message-ID: Thread-Topic: INFO and ISUP Thread-Index: AcexNfesNm477B0pEdy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] INFO and ISUP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I cringe every time someone says, "The only acceptable use for INFO is for ISUP." ALL of the arguments that apply to "One cannot use INFO for foo" apply to why "One cannot use INFO for ISUP." The INFO method is NOT to "carry [arbitrary] mid-session information between SIP user agents" as RFC 2976 posits. The one and only one reason one can use INFO for ISUP today is because the method is ONLY defined for ISUP. Said another way: the identifier 0x49 0x4E 0x46 0x4F has *NOTHING* to do with INFO. It would have much better been called 0x4E 0x53 0x55 0x50 (ISUP). For legacy reasons, and because we really are talking about a bunch of bits, not English, I would not offer we change the name of the method. However, I would make it clear that the method is NOT the general purpose method described in RFC 2976. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqz-0002Xe-8H; Mon, 18 Jun 2007 02:36:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Aqx-0002XN-Q0 for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Aqx-0002X7-Fc for sip@ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Aqw-0007R6-2Y for sip@ietf.org; Mon, 18 Jun 2007 02:36:43 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6aemm010846 for ; Sun, 17 Jun 2007 23:36:40 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6ab9p017650 for ; Sun, 17 Jun 2007 23:36:39 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 18:19:35 +0900 From: Eric Burger To: Message-ID: Thread-Topic: INFO and ISUP Thread-Index: AcexNfesNm477B0pEdy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Sip] INFO and ISUP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I cringe every time someone says, "The only acceptable use for INFO is for ISUP." ALL of the arguments that apply to "One cannot use INFO for foo" apply to why "One cannot use INFO for ISUP." The INFO method is NOT to "carry [arbitrary] mid-session information between SIP user agents" as RFC 2976 posits. The one and only one reason one can use INFO for ISUP today is because the method is ONLY defined for ISUP. Said another way: the identifier 0x49 0x4E 0x46 0x4F has *NOTHING* to do with INFO. It would have much better been called 0x4E 0x53 0x55 0x50 (ISUP). For legacy reasons, and because we really are talking about a bunch of bits, not English, I would not offer we change the name of the method. However, I would make it clear that the method is NOT the general purpose method described in RFC 2976. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArA-0002lD-4g; Mon, 18 Jun 2007 02:36:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Ar9-0002hm-0g for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ar7-0002da-TQ for sip@ietf.org; Mon, 18 Jun 2007 02:36:53 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ar7-0007Rt-8y for sip@ietf.org; Mon, 18 Jun 2007 02:36:53 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6amD9011171; Sun, 17 Jun 2007 23:36:48 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUms017603; Sun, 17 Jun 2007 23:36:33 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:44 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 19:54:07 +0900 Subject: SIP-MIME or MIME? (was Re: [Sip] MIME: Nested bodies with option-tag?) From: Eric Burger To: Gonzalo Camarillo Message-ID: Thread-Topic: SIP-MIME or MIME? (was Re: [Sip] MIME: Nested bodies with option-tag?) Thread-Index: AcexQyxyayxfbh02Edy0uwAWy4mm/w== In-Reply-To: <465C252C.6030909@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org IMHO, this whole thread is threatening. Think of this analogy: SIP:3GPP::MIME:SIP-MIME We are going WAY down the slippery slope of defining something that looks like MIME, but is not MIME. This is bad. Or evil. It depends on your disposition [sic]. If you want to know how that feels, what is your visceral response to Service Indicator? Well, that is how the MIME community responds to proposals that say, "we'll take MIME, but have it operate differently, but call it MIME." I know, no matter what we do here, there will be a 3GPP-MIME :-( For example, RFC 3204, referenced by the draft, is NOT the normative reference for the handling parameter. RFC 3204 describes SIP-ISUP interworking. It happens to describe a SIP-specific handling parameter. RFC 3459 is the normative reference for the handling parameter, which includes its use in SIP, as well as general-purpose MIME. I would offer the description for the motivation for the handling parameter in RFC 3459 is more relevant to SIP today than the description in 3204. [As a historical note, the text for RFC 3459 pre-dates RFC 3204 by 2 years, but had a stupid dependency on another document that didn't pop until 2003. That was my fault.] I do NOT buy the argument there are too many broken implementations to do the right thing. In that case, jettison the whole MIME infrastructure and build something you like (any takers for XCAP?). Do the right thing now, and say, "MIME is MIME." You even get some benefits, like a bunch of open source MIME implementations that one can use, rather than hacking these implementations to do SIP-specific stuff. On 5/29/07 9:05 AM, "Gonzalo Camarillo" wrote: > Hi, > > what I am hearing is that there are implementations out there that > support multipart but not nested. Therefore, we need to decide two things: > > 1) do we want to have a MUST for multipart and a SHOULD for nested? I > would say that we should have the same level (e.g., MUST, if we decided > that MUST is appropriate) for both. > > 2) do we need a way for implementations that support multipart but not > nested to be quickly updated to, at least, report that fact with an > error response? This may make sense. > > Cheers, > > Gonzalo > > Paul Kyzivat wrote: >> More or less repeating what I said before: >> >> I expect we do have to account in some way for implementations that have >> already been deployed, in absence of a clarifying document. Exactly how >> we deal with that is still TBD. >> >> But as we define what is required to support this in the future, I think >> there is *no* benefit to defining two levels of support - full and >> partial. Anybody that sets out to provide support for this document >> should be expected to do it all - its not that much harder. >> >> Paul >> >> Christer Holmberg (JO/LMF) wrote: >>> Hi, >>>> I wonder whether we should define an option-tag for the support of >>>> nested bodies. >>>> >>>> I don't think there's a lot to be gained from defining such an >>>> option-tag. The sender should already be aware that there is a risk >>>> the recipient can't understand nested bodies, and have arranged for >>>> suitable fallbacks. Conversely, the recipient should (at least) be >>>> able to skip the nested multipart body part in the proper "I don't >>>> understand this body part" way. All an option-tag would do is allow >>>> the sender to not add a fallback. >>> >>> In that case we need some specific text saying that if the receiver does >>> not support nested multiparts it MUST do-this-and-do-that. >>> >>> Because, as I said earlier, I don't think we will achieve what we want >>> by saying that one MUST be able to parse nested multiparts. It can be >>> rather tricky to implement (depending on how the parser is implemented, >>> though), and since there aren't really any use-cases out there yet I am >>> pretty sure some people will choose not to implement it (and saying that >>> people are not compliant in that case will not really help from an >>> interop perspective). So, because of that I think it would be good not >>> to mandate the support of nested multiparts, but to mandate appropriate >>> behavior if not supported - just like in any other case when a MIME body >>> contains an unsupported but required content type. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol Use >>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>> sipping@ietf.org for new developments on the application of sip >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ar5-0002ZC-1r; Mon, 18 Jun 2007 02:36:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Ar3-0002Z1-9k for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ar2-0002Yt-Vt for sip@ietf.org; Mon, 18 Jun 2007 02:36:48 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ar2-0007RO-IO for sip@ietf.org; Mon, 18 Jun 2007 02:36:48 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6akCC011166; Sun, 17 Jun 2007 23:36:46 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUmq017603; Sun, 17 Jun 2007 23:36:31 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:43 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 19:41:18 +0900 Subject: Re: [Sip] MIME: Nested bodies with option-tag? From: Eric Burger To: , Message-ID: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? Thread-Index: AcexQWIWoORTDB00Edy0uwAWy4mm/w== In-Reply-To: <200706032247.l53MlnaX026533@dragon.ariadne.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Correct. That is the mechanism specified by RFC 3459. On 6/3/07 6:47 PM, "Dale.Worley@comcast.net" wrote: > > From: "DRAGE, Keith \(Keith\)" > > Well, at the moment, what I am trying to do is get some understanding of > what we should scope as valid SIP work. > > I've been busy, so I may be behind in the discussion, but it's not > clear to me that there is anything that needs to be done specifically > for SIP. I may well be wrong, but my impression is that MIME already > has the features and specifications neede so that a receiver can > decide whether it has adequately "understood" the document when it > only understands some components. These mechanisms are all inherited > by SIP and I would expect be a sufficient set of rules. > > E.g., a UAC that sends a request with a multipart body must expect > that some UASs will respond with 415, and have some strategy in place > for dealing with that situation. Similarly, a UAC that sends a nested > multipart body must expect that some UASs will be unable to process > the nested multipart, and will either ignore it or reject the request > (as specified), and the UAC must be prepared to deal with that > situation. > > Is there a reason we need to define new, narrower subsets of allowed > behaviors and define a SIP mechanism to negotiate these? > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:37:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArF-00037n-1g; Mon, 18 Jun 2007 02:37:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ArD-00032J-5L for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:36:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArC-0002yr-8p for sip@ietf.org; Mon, 18 Jun 2007 02:36:58 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArB-0007W2-Df for sip@ietf.org; Mon, 18 Jun 2007 02:36:58 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6ar6R011256; Sun, 17 Jun 2007 23:36:53 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUn0017603; Sun, 17 Jun 2007 23:36:39 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:46 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 20:11:48 +0900 Subject: Re: [Sip] MIME: MIME when only one body type From: Eric Burger To: "Christer Holmberg (JO/LMF)" , Gonzalo Camarillo Message-ID: Thread-Topic: [Sip] MIME: MIME when only one body type Thread-Index: Aceiqh9o63lt6nIhTcOZvaqPJSYHEgASGY3gACLmkZAACvSqkAABXcagAAL/vjADYo8Qow== In-Reply-To: <7374777208BDC7449D5620EF9423256704941F26@esealmw113.eemea.ericsson.se> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org 1. if you can parse MIME, you can handle multipart/mixed with only a single body part. 2. SIP has had MIME for a very long time. I know an implementation that handled multipart/mixed since 2001 ;-) 3. If your UAS can handle MIME, but not multipart/* with a single attachment, then it is your UAS *implementation* that is broken. 4. Saying "SHOULD NOT, MUST NOT, ... have a single body part in a multipart/*" is senseless. If it is MIME, it certainly MAY have a single body part. The correct answer is: Therefore, this document RECOMMENDS UAs NOT use a 'multipart' body when there is only one body part. This document RECOMMENDS UACs NOT nest one 'multipart/mixed' within another unless there is a need to reference the nested one (i.e., using the Content ID of the nested body part). This document RECOMMENDS UAs NOT nest one 'multipart/alternative' within another. One might want to put text in describing why we recommend that. Namely, it is wasteful in network resources and CPU resources as the recipient. To be clear, RFC 2046 allows a multipart to have a single sub-part, so if we do MIME, we allow single sub-parts. On 5/31/07 3:46 PM, "Christer Holmberg (JO/LMF)" wrote: > > Hi, > >> I agree with Dan. >> >> I don't understand the use case in SIP of sending a Multipart >> with only one body. > > Again, I think I've seen INFOs and/or BYEs carrying ISUP informatio in > multipart, without any other body (unfortunately I have to use the word > "think", because I don't have any real examples in front of me :) > > But, I have nothing against saying that one SHOULD NOT (or even MUST > NOT) SEND it. But, I do think one should be prepared to RECEIVE such > messages, in order to be backward compatible with existing > implementations which may not be fully compliant the draft. > > And, regarding Dan's example: if a client is not able to handle > multipart carrying only SDP, I don't think it will be able to handle a > multipart carrying SDP and something else either - and we will have the > problem Francois presented earlier (the multipart, and the SDP innit, is > thrown away). > > Regards, > > Christer > > > > >>> -----Original Message----- >>> From: Dan Wing [mailto:dwing@cisco.com] >>> Sent: Thursday, May 31, 2007 10:38 >>> To: 'Christer Holmberg (JO/LMF)'; sip@ietf.org >>> Cc: 'Gonzalo Camarillo (JO/LMF)'; Audet, Francois (SC100:3055) >>> Subject: RE: [Sip] MIME: MIME when only one body type >>> >>> >>>>> Unless there is another case that it's useful for SIP, I >> think it >>>>> could only harm interoperability. >>>> >>>> Like I said, it may be used for transporting ISUP >>> information. Maybe >>>> Francois has more information? >>> >>> Implementations may well be doing multipart/mixed and >> including only >>> one bodypart. I completely agree that might be happening. >>> >>>> Also, if a client is going to support multipart anyway, I >> don't see >>>> how it would harm interoperability. >>> >>> By doing that, you are teasing fate, and you aren't "being >>> conservative in what you send". Afterall, it's the >> receiver (not the >>> sender) of the MIME that may have difficulties. >>> >>>> I would be very surprised if a client supports MIME with multiple >>>> bodies, but not with a single body... >>> >>> Yep, but it isn't the client that I'm so worried about. I >> expect if >>> you sent a multipart containing one part (application/sdp), >> you would >>> find disasterous interoperability. >>> >>> -d >>> >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:37:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArL-0003QT-2V; Mon, 18 Jun 2007 02:37:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ArF-00038Z-ER for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArD-00035Z-Sg for sip@ietf.org; Mon, 18 Jun 2007 02:36:59 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArC-0007WH-Qw for sip@ietf.org; Mon, 18 Jun 2007 02:36:59 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6atEB011265; Sun, 17 Jun 2007 23:36:55 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUn2017603; Sun, 17 Jun 2007 23:36:40 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:47 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 20:14:37 +0900 From: Eric Burger To: Gonzalo Camarillo Message-ID: Thread-Topic: SIP-body-handling Open Issue 1 Thread-Index: AcexRgmVSBiSxB05Edy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: sip@ietf.org Subject: [Sip] SIP-body-handling Open Issue 1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Allowing multiple multipart/alternative sub-parts with the same content type is very subtle. The direct answer is, "no, one may not have identical alternatives." The subtlety is that one CAN have two multipart/alternative sub-parts with the same Content-Type base. For example, I can have (stealing liberally from RFC 2046): Content-Type: multipart/alternative; boundary=42 Content-ID: --42 Content-Type: text/plain; charset=us-ascii My badly formatted alternative. --42 Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.example.com"; expiration="Fri, 14 Jun 2008 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: --42 Content-Type: message/external-body; access-type=mail-server server="listserv@example.net; expiration="Fri, 14 Jun 2008 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: get RFC-MIME.DOC --42-- Notice that two of the alternatives are message/external-body with types application/postscript. However, the parameters of the multipart/alternative Content-Type are different, rendering the Content-Types different. So, if the question is can I have two alternatives of type "mumble/foo", the answer is, "Yes, you may. For example, Content-Type: mumble/foo;param1=bar and Content-Type: mumble/foo:param1=foobar are the same type but different contents" If the question is can I have two alternatives that are the *identical* content type, like "mumble/foo;param1=bar" and "mumble/fool; param1=bar", then the answer is, "No, you may not." Just as in SIP, the MIME process needs to be able to determine if or how to handle a given body part purely from inspecting the headers. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:37:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArY-0003wl-JJ; Mon, 18 Jun 2007 02:37:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ArH-0003IE-PB for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArF-00039n-Bl for sip@ietf.org; Mon, 18 Jun 2007 02:37:01 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArE-0007WW-I2 for sip@ietf.org; Mon, 18 Jun 2007 02:37:01 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6aoXd011180; Sun, 17 Jun 2007 23:36:50 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUmu017603; Sun, 17 Jun 2007 23:36:35 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:45 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 20:11:01 +0900 Subject: Re: [Sip] MIME: Nested bodies with option-tag? From: Eric Burger To: Gonzalo Camarillo Message-ID: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? Thread-Index: AcexRYjXx63u8x04Edy0uwAWy4mm/w== In-Reply-To: <465D3B74.8060200@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Going a step further: if SIP goes beyond the standard MIME processing, I would offer that rather than use the hammer of the 1990's (MIME), we move to the hammer of the 2000's (XML). :-)) On 5/30/07 4:53 AM, "Gonzalo Camarillo" wrote: > Hi, > > what Keith says makes sense. I believe mandating support for multipart > in SIP is a SIP-specific problem. Mandating suppport for > multipart/alternative is also a SIP-specific problem, since a > SIP-specific problem such as the transition to new session description > formats depends on that. > > However, specifying if an implementation that supports multipart should > support nested body parts or not is something more general on which the > email folks have a lot of experience. > > Cheers, > > Gonzalo > > > DRAGE, Keith (Keith) wrote: >> Well, at the moment, what I am trying to do is get some understanding of >> what we should scope as valid SIP work. >> >> We need to be able to understand why something that is clearly a generic >> problem for specification of nested MIME bodies merits a SIP specific >> solution. >> >> So: >> >> - is a generic solution already documented elsewhere? >> >> - if a generic solution is not documented elsewhere, should one be >> documented, rather than a specific SIP solution? >> >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Sent: Wednesday, May 30, 2007 8:52 AM >>> To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>> Cc: sip@ietf.org >>> Subject: RE: [Sip] MIME: Nested bodies with option-tag? >>> >>> >>> Hi Keith, >>> >>>> Once we get down to a decision of supporting nested versus not >>>> supporting nesting, presumably we are then entirely in the >>> realm of the >>>> multipart coding itself. >>>> >>>> Could I ask someone to elaborate on what generic >>> requirements already >>>> exist within multipart/mime in this respect, before we start >>> looking at >>>> defining SIP specific rules or indications? >>> >>> I am very sure that I have seen text related to the support >>> of nested multiparts, and what nodes are expected to support, >>> somewhere, but I yet have not found it. >>> >>> Regards, >>> >>> Christer >>> >>> >>>> >>>> Regards >>>> >>>> Keith >>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg (JO/LMF) >>>>> [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Tuesday, May 29, 2007 2:47 PM >>>>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>>>> Cc: sip@ietf.org >>>>> Subject: RE: [Sip] MIME: Nested bodies with option-tag? >>>>> >>>>> >>>>> Hi, >>>>> >>>>> My main concern is not what wording (SHALL, MUST, etc) we use. >>>>> >>>>> The issue is that I think we need text saying what >>> implementations >>>>> that DO NOT support alternative and/or nested shall do. If >>>> we say that >>>>> they shall reject the message I believe that many of the existing >>>>> implementations will be compliant with the spec. >>>>> >>>>> And, if we give the possibility to simply reject the message, I >>>>> believe it will be easier to get people to change their >>>>> implementations, if they currently simply discard >>>> alternative and/or >>>>> nested today. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>> Sent: 29. toukokuuta 2007 16:06 >>>>>> To: Paul Kyzivat >>>>>> Cc: Christer Holmberg (JO/LMF); sip@ietf.org >>>>>> Subject: Re: [Sip] MIME: Nested bodies with option-tag? >>>>>> >>>>>> Hi, >>>>>> >>>>>> what I am hearing is that there are implementations out >>>> there that >>>>>> support multipart but not nested. Therefore, we need to >>> decide two >>>>>> things: >>>>>> >>>>>> 1) do we want to have a MUST for multipart and a SHOULD for >>>>> nested? I >>>>>> would say that we should have the same level (e.g., MUST, if we >>>>>> decided that MUST is appropriate) for both. >>>>>> >>>>>> 2) do we need a way for implementations that support >>>>> multipart but not >>>>>> nested to be quickly updated to, at least, report that >>>> fact with an >>>>>> error response? This may make sense. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>>> More or less repeating what I said before: >>>>>>> >>>>>>> I expect we do have to account in some way for >>>>> implementations that >>>>>>> have already been deployed, in absence of a >>> clarifying document. >>>>>>> Exactly how we deal with that is still TBD. >>>>>>> >>>>>>> But as we define what is required to support this in the >>>>> future, I >>>>>>> think there is *no* benefit to defining two levels of >>>>>> support - full >>>>>>> and partial. Anybody that sets out to provide support >>> for this >>>>>>> document should be expected to do it all - its not that >>>>> much harder. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>>>> Hi, >>>>>>>>> I wonder whether we should define an option-tag for the >>>>>> support of >>>>>>>>> nested bodies. >>>>>>>>> >>>>>>>>> I don't think there's a lot to be gained from >>>> defining such an >>>>>>>>> option-tag. The sender should already be aware that >>>>>> there is a risk >>>>>>>>> the recipient can't understand nested bodies, and have >>>>>> arranged for >>>>>>>>> suitable fallbacks. Conversely, the recipient should (at >>>>>> least) be >>>>>>>>> able to skip the nested multipart body part in the proper >>>>>> "I don't >>>>>>>>> understand this body part" way. All an option-tag would >>>>>> do is allow >>>>>>>>> the sender to not add a fallback. >>>>>>>> >>>>>>>> In that case we need some specific text saying that if the >>>>>> receiver >>>>>>>> does not support nested multiparts it MUST >>> do-this-and-do-that. >>>>>>>> >>>>>>>> Because, as I said earlier, I don't think we will >>>>> achieve what we >>>>>>>> want by saying that one MUST be able to parse nested >>>>>> multiparts. It >>>>>>>> can be rather tricky to implement (depending on how the >>>>> parser is >>>>>>>> implemented, though), and since there aren't really any >>>>>> use-cases out >>>>>>>> there yet I am pretty sure some people will choose not to >>>>>> implement >>>>>>>> it (and saying that people are not compliant in that >>>>> case will not >>>>>>>> really help from an interop perspective). So, because of >>>>>> that I think >>>>>>>> it would be good not to mandate the support of nested >>>>>> multiparts, but >>>>>>>> to mandate appropriate behavior if not supported - just >>>>>> like in any >>>>>>>> other case when a MIME body contains an unsupported but >>>>>> required content type. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>> This list is for NEW development of the core SIP >>> Protocol Use >>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>> current sip Use >>>>>>>>> sipping@ietf.org for new developments on the >>>> application of sip >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP >>> Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>> current sip Use >>>>>>>> sipping@ietf.org for new developments on the >>> application of sip >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>> sip-implementors@cs.columbia.edu for questions on >>>> current sip Use >>>>>>> sipping@ietf.org for new developments on the >>> application of sip >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>> sipping@ietf.org for new developments on the application of sip >>>>> >>>> >>> >> > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:37:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ard-00042r-8P; Mon, 18 Jun 2007 02:37:25 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ArG-0003Eg-JT for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:37:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArE-00036i-Ld for sip@ietf.org; Mon, 18 Jun 2007 02:37:00 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArE-0007WV-8f for sip@ietf.org; Mon, 18 Jun 2007 02:37:00 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6augI011305; Sun, 17 Jun 2007 23:36:56 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6aUn4017603; Sun, 17 Jun 2007 23:36:42 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:48 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 20:33:11 +0900 From: Eric Burger To: Gonzalo Camarillo Message-ID: Thread-Topic: SIP-body-handling Open Issue 3 Thread-Index: AcexSKGU4Dj0XB07Edy0uwAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: sip@ietf.org Subject: [Sip] SIP-body-handling Open Issue 3 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I do not think one can say what the Content-Disposition of a multipart/* body part should be. From RFC 2183: If a Content-Disposition header is used on a multipart body part, it applies to the multipart as a whole, not the individual subparts. The disposition types of the subparts do not need to be consulted until the multipart itself is presented. When the multipart is displayed, then the dispositions of the subparts should be respected. We already have a compatible-with-MIME solution. Mark the Content-Disposition of the multipart/* as render, session, or inline with the needed handling parameter, and have the Content-Disposition of the sub-parts be whatever they really need to be (if not render). The logic is simply to say what you mean. It really is just a suggestion. If we are talking about a multipart/alternative describing sessions, then the Content-Disposition should be session. Of course, you could have Content-Disposition be foobar (or, better yet, inline), so long as (1) the UAS does not barf and (2) the real Content-Dispositions are present on all of the sub-parts. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 02:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0As5-0004bT-J1; Mon, 18 Jun 2007 02:37:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ArN-0003X5-8q for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 02:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ArI-0003LN-BB for sip@ietf.org; Mon, 18 Jun 2007 02:37:04 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ArH-0007Yz-JW for sip@ietf.org; Mon, 18 Jun 2007 02:37:04 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5I6agDL011139; Sun, 17 Jun 2007 23:36:42 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5I6ab9r017650; Sun, 17 Jun 2007 23:36:40 -0700 Received: from 172.24.28.172 ([172.24.28.172]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Jun 2007 06:36:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 17 Jun 2007 18:52:58 +0900 Subject: Re: [Sip] INFO usage (or not) From: Eric Burger To: Keith Drage , IETF SIP List Message-ID: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/w== In-Reply-To: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org How about this: This document describes why the Session Initiation Protocol (SIP) INFO method, introduced in RFC 2976, has serious issues with any use outside its use as a transport mechanism for ISDN User Part (ISUP) call signaling in SIP-signaled networks. In the years since the introduction of the INFO method, the IETF has published numerous, interoperable extensions to SIP. This document explains why there are INFO-based, proprietary protocols in the wild; the flaws of using INFO; and prescriptions for how to use existing, interoperable SIP mechanisms to accomplish most any of these tasks. My personal preference is for the document to be Standards Track and be a Work Group chartered item. The reason is that for this document to be useful, it MUST update RFC 2976. If it updates RFC 2976, then newbies get the pointer when the download RFC 2976, pointing them to this document, before they go off, create draft-mumble-foo-over-INFO, and get flamed on the list. The essence of the normative content of the document is, "one MUST NOT use INFO for anything other than transporting ISUP or QSIG messages." Because the normative content is so thin, I could understand not saying that and making the document Informational (or BCP). However, I really and truly believe that will significantly reduce the impact the document will have. Outline: Introduction - Requirements for UA-to-UA signaling - The INFO method - The INFO method for ISUP signaling Issues with INFO - No or incomplete negotiation - No real identification of payload purpose on receipt Alternatives to INFO - State Updates: SUBSCRIBE / NOTIFY - DTMF Transport: KPML (an example of state updates) - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP - Prescriptions for deciding which method is appropriate under what circumstances Update to RFC 2976 - Limiting use of INFO to ISUP transport only Security Considerations On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)" wrote: > (As WG chair) > > We have got a number of threads floating round on INFO usage, and it > would be nice to identify this into a potential body of work, and see if > there is support for it. > > We have two previous drafts that never went anywhere, although contents > of both carried support in the WG at the time: > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > The Session Initiation Protocol (SIP) INFO method defines a means for > transporting mid-dialog application layer data between user agents. > Its initial use was to support the transport of ISUP mid-call > messages which could not be mapped to any other SIP request method. > However, since its initial usage for that purpose, INFO has seen > widespread abuse as a means for introducing non-standard and > non-interoperable extensions to SIP. For this reason, we now believe > INFO should be considered harmful, and therefore, deprecated in its > current form. > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > The SIP INFO method (RFC 2976) establishes a method by which > applications may transfer application-specific information within a > SIP dialog. However, RFC 2976 does not provide a mechanism for > describing and documenting an application of INFO, nor does it > provide a mechanism by which applications may negotiate such uses. > This document provides a framework for documenting and naming > specific uses of INFO (called INFO packages), for registering those > package names with IANA, and for negotiating the support for various > INFO packages between applications using SIP. > > In the thread so far there have also been suggestions that cover: > > - support to mediactrl for their discussion on requirements > - something for hitchhiker's guide to point to: > - something that answers all the questions that recur on this list > on INFO usage > - "I've been getting a lot of offline questions asking for the > "right" way to carry information related to the session-usage (often > information that's being tunneled around from companion or gatewayed > protocols)." > - INVITE dialog usage only, or already covered by RFC 2976 > - It would be OK with me if we ALSO had this type of guidance > ("don't look HERE, look over THERE") available ("stated strongly enough > in an easy to stumble across place"), but if coming up with that > guidance takes more than about a week, I don't see a lot of reason to > hold up on "don't go there" > while we explore alternatives. > - INFO and DTMF > - XML payloads > - But people really need is guidance on when to use INFO, when to > use events, and when to use something entirely different. > - identification of purpose of info (Content-Type? - impacted by > multipart/mixed) > - any framework for control of usages (IANA registration? - RFC > 3427 update) > > Would anybody out there like to have a go at drafting an abstract for a > potential WG deliverable (and also identifying level - Info, BCP, > standards track) and submitting it to the list for discussion. Remember > an abstract needs to: > > ------------------------------------------------------------------------ > ------- > Every RFC must have an Abstract section following the Copyright notice. > An Abstract will typically be 5-10 lines. An Abstract of more than 20 > lines is generally not acceptable. > > The Abstract section should provide a concise and comprehensive overview > of the purpose and contents of the entire document, to give a > technically knowledgeable reader a general overview of the function of > the document. In addition to its function in the RFC itself, the > Abstract section text will appear in publication announcements and in > the online index of RFCs. > > Composing a useful Abstract generally requires thought and care. Usually > an Abstract should begin with a phrase like "This memo ..." or "This > document ...". A satisfactory abstract can often be constructed in part > from material within the Introduction section, but a good abstract will > be shorter, less detailed, and perhaps broader in scope than the > Introduction. Simply copying and pasting the first few paragraphs of the > Introduction is tempting, but it may result in an Abstract that is both > incomplete and redundant. Note also that an Abstract is not a substitute > for an Introduction; the RFC should be self-contained as if there were > no Abstract section. > > An Abstract should be complete in itself; it should not contain > citations unless they are completely defined within the Abstract. > Abbreviations appearing in the Abstract should generally be expanded in > parentheses. There is a small set of reasonable exceptions to this rule > (see guidelines on abbreviations, above.) > ------------------------------------------------------------------------ > ------ > > And as such should give a clear idea of whether there is anything we > should charter here or not. > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 03:45:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bv6-0006El-1c; Mon, 18 Jun 2007 03:45:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Bv4-0006Du-Ce for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 03:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Bv3-0006Di-RC for sip@ietf.org; Mon, 18 Jun 2007 03:45:01 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Bv3-0006MW-9w for sip@ietf.org; Mon, 18 Jun 2007 03:45:01 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l5I7isHM007203; Mon, 18 Jun 2007 09:44:54 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l5I7in7d031572; Mon, 18 Jun 2007 09:44:54 +0200 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 09:44:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-ietf-sip-saml-02 Date: Mon, 18 Jun 2007 09:44:38 +0200 Message-ID: <6A18D243963B7447AC1A36583F78EEDA01F7E39B@MCHP7I6A.ww002.siemens.net> In-Reply-To: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-ietf-sip-saml-02 Thread-Index: Aces0fucrfmQnBbDRJiKX5ZPB1I70QEqSXPQ References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> From: "Fries, Steffen" To: "DRAGE, Keith (Keith)" , "IETF SIP List" X-OriginalArrivalTime: 18 Jun 2007 07:44:49.0967 (UTC) FILETIME=[8CCD3BF0:01C7B17C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I just had a quick review of the SIP-SAML activities. I found mostly nits, which ware below, the draft generally seems mature to me. - 1 Introduction (page 3) maybe it is worth mentioning in the introduction already that this ID only=20 considers "call by reference" for the assertions and does not provide means for=20 sending the assertion directly. - 3.1 SAML assertions (page 7) "Explaining how the assertion was made, for example. " Sounds like an example would follow,=20 which does not. I suggest removing "for example" - 4 Specification scope (page 9), in the discussion paragraph: "However, The ..." -> should be "However, the ..." "participating entites ..." -> "participating entities ..." - 5. Emplying SAML in SIP (page 11) "seperatey" -> "separately" - 6.1.2 Profile Overview (page 14) "Although this profile is overview is cast in terms of a SIP INVITE ..." There is something wrong with this sentence - 6.1.3.2 (page 19) procedes -> proceeds Ciao Steffen =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Tuesday, June 12, 2007 11:14 AM > To: IETF SIP List > Subject: [Sip] draft-ietf-sip-saml-02 >=20 > (As WG chair) >=20 > Well it seems there is interest in this work, but it is not=20 > getting the attention it deserves. > =20 > Some people also seem to think it is almost there, but we=20 > have no way of judging that without seeing the what comments=20 > are being made against the document (or of course reviewing=20 > it ourselves). >=20 > This week is a quiet week (we supposedly finished our current=20 > WGLC yesterday, and we are not yet ready to initiate another=20 > one, and the draft closured deadlines for the forthcoming=20 > IETF are still a little bit away). > =20 > We therefore task the working group to take the next 7=20 > calendar days (ending Monday 18th June) to open up: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt >=20 > And for everyone to post at least one comment on the document=20 > to the SIP list. Posts can cover any of: >=20 > - completeness - is there something missing? > - applicability - does it identify and solve a problem? > - readability - I didn't understand what it was trying to tell me? > - correctness of technical solution - the solution is flawed? > - nits >=20 > We would also welcome suggestions as to whether review is=20 > needed by other groups than the SIP WG. >=20 > And of course if you read it and find it absolutely perfect,=20 > send the chairs a mail at least to tell us. >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 03:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C2h-0007m6-KB; Mon, 18 Jun 2007 03:52:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0C2g-0007m1-IU for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 03:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C2g-0007lt-8Z for sip@ietf.org; Mon, 18 Jun 2007 03:52:54 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0C2f-0007yY-Hu for sip@ietf.org; Mon, 18 Jun 2007 03:52:54 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 40FFB20709; Mon, 18 Jun 2007 09:52:52 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-d9-467639d426d1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1FB602040C; Mon, 18 Jun 2007 09:52:52 +0200 (CEST) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 09:52:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 09:52:54 +0200 Message-ID: <3C26DE1DC0C6724B8928D40F216ECFB004C8928E@esealmw103.eemea.ericsson.se> In-Reply-To: <464D51DC.5080909@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions on XCAP Diff Event draft Thread-Index: AceZG+9WC6fVt9bvSRqM0X27qOJ6vQYX3Wng From: "Sofie Lassborn (TN/EAB)" To: "Jari Urpalainen" X-OriginalArrivalTime: 18 Jun 2007 07:52:51.0906 (UTC) FILETIME=[AC0F4A20:01C7B17D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: sip@ietf.org Subject: [Sip] RE: Questions on XCAP Diff Event draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jari, I have some more questions regarding the last paragraph. Please see below. Best regards, Sofie=20 -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 Sent: den 18 maj 2007 09:12 To: Sofie Lassborn (TN/EAB) Cc: sip@ietf.org Subject: Re: Questions on XCAP Diff Event draft ext Sofie Lassborn (TN/EAB) wrote: > > Hi Jari, > > I have some thoughts and questions regarding the XCAP Diff Event draft > (draft-urpalainen-sip-xcap-diff-event-01). > What will the notification look like if a requested document cannot be > found? No body or only element? > good catch, actually the current xcap-diff format requires at least one document update (but it should be fixed), so either of your proposals should work. > > What does it mean if a notification contains the document element with > doc-selector but no etag attributes? > This is not defined in xcap-diff format, as it is sort of an error case with documents. With xcap-component subscription it is somewhat vague.=20 When etags are included, you could e.g. do a conditional replace based on them. So perhaps it is better to add etags always, certainly I don't want any negotiations about this. > > OMA has implemented an architecure where the XCAP server has been=20 > split up into so called XCAP Document Management Servers (XDMS). Each=20 > XDMS handles separate AUIDs. If a subscription is for several=20 > documents distributed over several XDMSes (different auids), what=20 > should then the notification look like if there are some documents=20 > that don't exist or directories that are empty and there are some=20 > documents that cannot be reached because one XDMS does not answer? > Good question. I could do a counterquestion, why did OMA do that, and instead let the implementations figure these out ? I mean this introduces a lot of complexity and several difficult error cases. But the intention here (in the i-d) is to do what is typical in the ietf, i.e. just to define the interface and let the implementations do the rest. But back to the question, the i-d says that you send in the initial notify request what you can "read", so probably you could still compose this from separate responses from several xdms, as results from different auids should be orthogonal. But hey, I really wouldn't personally like to implement it ;-). > > According to RFC 3265 the "pending" value of the Subscripton-State=20 > header indicates that the subscription has been received, but that=20 > policy information is insufficient to accept or deny the subscription=20 > at this time. Is the intention in section 4.7 in the draft that the=20 > subscription state should be pending if the resource the subscription=20 > is for cannot be found? What would then the subscription state be for=20 > a subscription for white space separated resources where some can be=20 > found and some cannot be found? > While using "pending" I was wandering that I'll produce somewhat confusing text..., I'll try to clarify this. > > Generation of a "first full response" notification might take time=20 > especially if the subscription is for several AUIDs, spread over=20 > several XCAP Document Management Servers, at the same time. Is there a > need for an "initial" initial notification that may be sent to the=20 > subscriber before the "full response" can be sent? > In practice, I wouldn't anticipate that you would need this empty body or neutral body notify, i.e. clients will most likely keep the state information based on the response of subscribe. But the spec allows to use it although null body interpretation with content-type header _is_ interesting. > > Chapter 4.7, second paragraph > It is unclear to me what is meant by "...it MUST fall back to sending=20 > all component changes again for this resource." Is the intention that=20 > the server shall send a "full response" as in an initial notification=20 > (my preferred interpretation)? Or is the intention that the server=20 > shall send several notifications with the patches not aggregated? > > Best regards, > Sofie > The latter, after sending the http reference, the server does not know when the client has really read the content, thus no aggregation allowed with "rapidly changing resources" [Sofie wrote:] I see aggregation as very useful in conjuction with rate limitation and throttle. An issue arrises though when a notification with aggregated patches becomes too large. According to you the notifier should then send all patches separately in several notifications but if rate limitation or throttle is being used the client might never catch up. Could it instead be the choise of the notifier if it wants to send a notification with only the document link (content indirection) or if it wants to send all patches separately? thanks, 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 sip-bounces@ietf.org Mon Jun 18 04:02:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CCF-0000rD-Mu; Mon, 18 Jun 2007 04:02:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0CCD-0000r5-HQ for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 04:02:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CCC-0000qw-Ve for sip@ietf.org; Mon, 18 Jun 2007 04:02:44 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0CCB-00020V-Ld for sip@ietf.org; Mon, 18 Jun 2007 04:02:44 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1211710ugf for ; Mon, 18 Jun 2007 01:02:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=ghvUyzhRokYhqqPrnuDAqVt6iiN09pPxctU66/Rg+11rffrBcJZ6dLlJxYADh7MCreFzflGCzVhW7g5fl5c3JqsHTTLKxHDtrBU4pH3HsCXsc9giujhosGwbRYpvaXx7t2jSaWsgCI8BpDCkSQiga3/mgx0HIw4qZEz4vBf6tTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Gnjv/SVg4fJFjqdBhQCAsArv14LJsxeMrYismIjyiWjqnxVWIvvMp3u2N9Ggfcfbe3sR43QQzjM1NNTVwJfY0FRNjkf0xzeNX4iIuB6AXSWv6MtAXmndRx59ppoZCp9ycH96PBeCSRqik1bNNN0+Q+2lDK5AZZPvVW67E+sXA7Q= Received: by 10.67.25.14 with SMTP id c14mr4853561ugj.1182153763002; Mon, 18 Jun 2007 01:02:43 -0700 (PDT) Received: by 10.67.86.16 with HTTP; Mon, 18 Jun 2007 01:02:42 -0700 (PDT) Message-ID: <52a9bccc0706180102u246a9e11k7fa39374e8426aba@mail.gmail.com> Date: Mon, 18 Jun 2007 13:32:42 +0530 From: "Jagan Mohan" To: "SIP list" MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Sip] Effect of SIP T1 timer value on T4 timer X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0886115319==" Errors-To: sip-bounces@ietf.org --===============0886115319== Content-Type: multipart/alternative; boundary="----=_Part_70422_24610465.1182153762972" ------=_Part_70422_24610465.1182153762972 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I would like to how T4 timer needs to be set, based on the value of T1? If round trip delay is, say 20s, then T1 needs to be set to 20s. To what value should T4 timer, needs to be set now? Should T4 needs to be set as (Actual value of T1)*(default value of T4/ default value of T1)? If yes, could you please explain the logic behind this. Thanks, Jagan ------=_Part_70422_24610465.1182153762972 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,

   I would like to how T4 timer needs to be set, based on the value of T1?
If round trip delay is, say 20s, then T1 needs to be set to 20s. To what value should T4 timer, needs to be set now? Should T4 needs to be set as (Actual value of T1)*(default value of T4/ default value of T1)? If yes, could you please explain the logic behind this.

Thanks,
Jagan
 
------=_Part_70422_24610465.1182153762972-- --===============0886115319== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0886115319==-- From sip-bounces@ietf.org Mon Jun 18 04:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CmT-0004GX-H5; Mon, 18 Jun 2007 04:40:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0CmR-00046F-GJ for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 04:40:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0CmR-000467-5X for sip@ietf.org; Mon, 18 Jun 2007 04:40:11 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0CmQ-0002So-L9 for sip@ietf.org; Mon, 18 Jun 2007 04:40:11 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5I8e8ag014497; Mon, 18 Jun 2007 10:40:08 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l5I8e76N000406; Mon, 18 Jun 2007 10:40:08 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:39:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 10:39:20 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758021496CA@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP Saml Review by Marcos Dytz Thread-Index: AcexhCp0JuWRzmnETQmce33Vf11P3w== From: "Tschofenig, Hannes" To: "SIP IETF" X-OriginalArrivalTime: 18 Jun 2007 08:39:21.0797 (UTC) FILETIME=[2AF6DF50:01C7B184] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ext Marcos Dytz Subject: [Sip] SIP Saml Review by Marcos Dytz X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Marcos Dytz implemented SIP Pay and I asked him to review the document. Here are his review comments: ----------------------------- Von: ext Marcos Dytz [mailto:marcos.dytz@gmail.com]=20 Gesendet: Montag, 18. Juni 2007 10:20 An: Tschofenig, Hannes Betreff: Re: SIP SAML Draft Review Hey Hannes, I finished my review. Here are my comments: Overall the draft is much more detailed (thus, better) than anything I've read before on SIP/SAML.=20 My points on possible improvements to be added. 1) I believe that it would be good to leave a bit the emphasis on authentication and providing different uses of the protocol (or, at least, specifying that it can be used to convey attributes, query for information, etc).=20 2) The SAML assertion profile sounds weird, although I never completely had a complete grasp of its meaning. I understand that it is connected with the implementation, but it never actually had any particular use to me (or I never gave it much attention). I rather see it as details that developers had to apply in order to have the implementation working and must be added to the specification in order to avoid interoperability issues.=20 3) I believe it is worth mentioning that one invalid condition locks the whole assertion. 4) I also believe that is worth mentioning that the Identity-Info is connected with CERTS and might go through deployment issues.=20 5) Is there something missing on 7.1? Sounded incomplete to me. 6) I believe that it is valid that together with signing part of the message, some fields are hashed in order to improve security. 7) The part of the AS as an authenticator and proxy could be further clarified.=20 Just some tips on how I believe it could be further improved. Again overall the draft is very good and understandable. Cheers Marcos PS: Grammar corrections (and suggestions). I've put changes under parentheses. * areas where the applicability to SIP (are) is widely desired. * Employing SAML in SIP necessitates devising a new SAML profile(s) and binding(s) because (the) those already specified in the SAMLv2=20 * specification set are specific to other use contexts (contexts of use sound more connected with general use of the term, no?), e.g., HTTP-based web browsing.=20 * 6.1. AS-driven SIP SAML URI-based Attribute ( )Assertion Fetch Profile (Double spacing)=20 * Since the AS (is) already being trusted to create and add the Identity header containing the SIP Identity Assertion, and to supply a pointer to its domain certificate, having it point instead to a SAML assertion conveying the domain certificate and possibly some user profile attributes, does not significantly alter the first-order security considerations examined in [RFC4474].=20 The last one was confusing to me. I re-wrote by having two sentences. Since the (is) AS already being trusted to create and add the Identity header containing the SIP Identity Assertion, and to supply a pointer to its domain certificate. By having it point instead to a SAML assertion conveying the domain certificate and possibly some user profile attributes does not significantly alter the first-order security considerations examined in [RFC4474].=20 * Although this profile (is) overview is cast in terms of a SIP INVITE transaction, the reader should note that the mechanism specified herein, and in [RFC4474], may be applied to any SIP request message. * the randomness requir(e)ments specified in Section 1.3.4 of [OASIS.saml-core-2.0-os]. * The value of the NotOnOrAfter XML attribute MUST be set to a time instant later than the value for(or of?) NotBefore. * 6.1.3.4. Verifier Dereferences HTTP-based SAML ( )URI Reference * the SIP SAML assertion profile specified herein (states) that the subject's SAML assertion must adhere to causes it to be not useful to arbitrary parties.=20 * Additionally, the assertion content dictated by the SAML assertion profile herein ensures (or provides?) ample evidence for a relying party to verify the assertion and its relationship with the received SIP request.=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 05:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0D7U-0008H9-Em; Mon, 18 Jun 2007 05:01:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0D7R-0008Gs-EY for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0D7Q-0008GR-Rl for sip@ietf.org; Mon, 18 Jun 2007 05:01:52 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0D75-0008So-Tk for sip@ietf.org; Mon, 18 Jun 2007 05:01:32 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 18 Jun 2007 11:01:30 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:01:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Sip] INFO usage (or not) X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 18 Jun 2007 11:01:29 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD4117667@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASb2EA From: "Jesske, R" To: , , X-OriginalArrivalTime: 18 Jun 2007 09:01:29.0875 (UTC) FILETIME=[428F7E30:01C7B187] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, Why should be RFC's that are now 6 Years out in the world be restricted? RFC 2976 clearly states for what INFO can be used. I'm concerned about implementations that works with INFO regarding the = rules defined within 2976. Many implementations work based on that RFC. Like define a MIME, put it = into INFO and it works. I thought also that INFO was defined to put in some end to end = information that shall be exchanged by UA's. Why to restrict such a use in such a case? If RFC 2976 will be changed is backward compatibility guaranteed? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Eric Burger [mailto:eburger@bea.com]=20 > Gesendet: Sonntag, 17. Juni 2007 11:53 > An: Keith Drage; IETF SIP List > Betreff: Re: [Sip] INFO usage (or not) >=20 >=20 > How about this: >=20 > This document describes why the Session Initiation Protocol (SIP) INFO > method, introduced in RFC 2976, has serious issues with any=20 > use outside its > use as a transport mechanism for ISDN User Part (ISUP) call=20 > signaling in > SIP-signaled networks. In the years since the introduction=20 > of the INFO > method, the IETF has published numerous, interoperable=20 > extensions to SIP. > This document explains why there are INFO-based, proprietary=20 > protocols in > the wild; the flaws of using INFO; and prescriptions for how to use > existing, interoperable SIP mechanisms to accomplish most any of these > tasks. >=20 >=20 > My personal preference is for the document to be Standards=20 > Track and be a > Work Group chartered item. The reason is that for this document to be > useful, it MUST update RFC 2976. If it updates RFC 2976,=20 > then newbies get > the pointer when the download RFC 2976, pointing them to this=20 > document, > before they go off, create draft-mumble-foo-over-INFO, and=20 > get flamed on the > list. The essence of the normative content of the document=20 > is, "one MUST > NOT use INFO for anything other than transporting ISUP or=20 > QSIG messages." >=20 > Because the normative content is so thin, I could understand=20 > not saying that > and making the document Informational (or BCP). However, I=20 > really and truly > believe that will significantly reduce the impact the=20 > document will have. >=20 >=20 > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate under what > circumstances > Update to RFC 2976 > - Limiting use of INFO to ISUP transport only > Security Considerations >=20 >=20 >=20 >=20 >=20 > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > wrote: >=20 > > (As WG chair) > >=20 > > We have got a number of threads floating round on INFO usage, and it > > would be nice to identify this into a potential body of=20 > work, and see if > > there is support for it. > >=20 > > We have two previous drafts that never went anywhere,=20 > although contents > > of both carried support in the WG at the time: > >=20 > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >=20 > > The Session Initiation Protocol (SIP) INFO method=20 > defines a means for > > transporting mid-dialog application layer data between=20 > user agents. > > Its initial use was to support the transport of ISUP mid-call > > messages which could not be mapped to any other SIP=20 > request method. > > However, since its initial usage for that purpose, INFO has seen > > widespread abuse as a means for introducing non-standard and > > non-interoperable extensions to SIP. For this reason,=20 > we now believe > > INFO should be considered harmful, and therefore,=20 > deprecated in its > > current form. > >=20 > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >=20 > > The SIP INFO method (RFC 2976) establishes a method by which > > applications may transfer application-specific=20 > information within a > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > describing and documenting an application of INFO, nor does it > > provide a mechanism by which applications may negotiate=20 > such uses. > > This document provides a framework for documenting and naming > > specific uses of INFO (called INFO packages), for=20 > registering those > > package names with IANA, and for negotiating the support=20 > for various > > INFO packages between applications using SIP. > >=20 > > In the thread so far there have also been suggestions that cover: > >=20 > > - support to mediactrl for their discussion on requirements > > - something for hitchhiker's guide to point to: > > - something that answers all the questions that recur on this list > > on INFO usage > > - "I've been getting a lot of offline questions asking for the > > "right" way to carry information related to the session-usage (often > > information that's being tunneled around from companion or gatewayed > > protocols)." > > - INVITE dialog usage only, or already covered by RFC 2976 > > - It would be OK with me if we ALSO had this type of guidance > > ("don't look HERE, look over THERE") available ("stated=20 > strongly enough > > in an easy to stumble across place"), but if coming up with that > > guidance takes more than about a week, I don't see a lot of=20 > reason to > > hold up on "don't go there" > > while we explore alternatives. > > - INFO and DTMF > > - XML payloads > > - But people really need is guidance on when to use INFO, when to > > use events, and when to use something entirely different. > > - identification of purpose of info (Content-Type? - impacted by > > multipart/mixed) > > - any framework for control of usages (IANA registration? - RFC > > 3427 update) > >=20 > > Would anybody out there like to have a go at drafting an=20 > abstract for a > > potential WG deliverable (and also identifying level - Info, BCP, > > standards track) and submitting it to the list for=20 > discussion. Remember > > an abstract needs to: > >=20 > >=20 > -------------------------------------------------------------- > ---------- > > ------- > > Every RFC must have an Abstract section following the=20 > Copyright notice. > > An Abstract will typically be 5-10 lines. An Abstract of=20 > more than 20 > > lines is generally not acceptable. > >=20 > > The Abstract section should provide a concise and=20 > comprehensive overview > > of the purpose and contents of the entire document, to give a > > technically knowledgeable reader a general overview of the=20 > function of > > the document. In addition to its function in the RFC itself, the > > Abstract section text will appear in publication=20 > announcements and in > > the online index of RFCs. > >=20 > > Composing a useful Abstract generally requires thought and=20 > care. Usually > > an Abstract should begin with a phrase like "This memo ..." or "This > > document ...". A satisfactory abstract can often be=20 > constructed in part > > from material within the Introduction section, but a good=20 > abstract will > > be shorter, less detailed, and perhaps broader in scope than the > > Introduction. Simply copying and pasting the first few=20 > paragraphs of the > > Introduction is tempting, but it may result in an Abstract=20 > that is both > > incomplete and redundant. Note also that an Abstract is not=20 > a substitute > > for an Introduction; the RFC should be self-contained as if=20 > there were > > no Abstract section. > >=20 > > An Abstract should be complete in itself; it should not contain > > citations unless they are completely defined within the Abstract. > > Abbreviations appearing in the Abstract should generally be=20 > expanded in > > parentheses. There is a small set of reasonable exceptions=20 > to this rule > > (see guidelines on abbreviations, above.) > >=20 > -------------------------------------------------------------- > ---------- > > ------ > >=20 > > And as such should give a clear idea of whether there is anything we > > should charter here or not. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 05:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DPD-0005Cn-Vv; Mon, 18 Jun 2007 05:20:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0DPC-0005CX-Eq for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DPC-0005CN-3H for sip@ietf.org; Mon, 18 Jun 2007 05:20:14 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DOv-0006fI-9k for sip@ietf.org; Mon, 18 Jun 2007 05:20:14 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A4517200B6; Mon, 18 Jun 2007 11:19:56 +0200 (CEST) X-AuditID: c1b4fb3e-b2038bb0000007e1-70-46764e3cde3d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 84C5E2008D; Mon, 18 Jun 2007 11:19:56 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:19:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Mon, 18 Jun 2007 11:19:55 +0200 Message-ID: <7374777208BDC7449D5620EF94232567056C1E21@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7g References: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , "Keith Drage" , "IETF SIP List" X-OriginalArrivalTime: 18 Jun 2007 09:19:56.0335 (UTC) FILETIME=[D60FE3F0:01C7B189] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I am very concerned some some people use the word "newbies", and make it = sound that people using INFO are beginners which have no clue about SIP. Also, I have never heard about interoperability problems with INFO. One = reason people are using INFO for certain things IS in order to interop = with other implementations. I am also confused that people seem to think that INFOs will start = flying around for no reason, without the sender having any clue about = whether the receiver will understand them or not. As we have discussed, = there ARE mechanisms in SIP to negotiate what content types etc entities = support. Yes, MAYBE we need to extend that (e.g. being able to indicate = which methods can be used to carry a specific content type), if what we = have is not enough. But, to me that is not the same thing has having = "tons of problem". Having said that, if there are issues with INFO, I have nothing against = discussing them. But, if you are going to talk about alternative = solutions, you also need to look at possible issues with those (having = to set up multiple dialogs just in order to send some DTMFs associated = with another dialog etc).=20 We can sit in our meeting rooms and = write whatever you-must-to-this-and-you-must-not-do-that documents, but = if we don't care about the feedback we get from the real world OUTSIDE = the meeting room it won't help much. In the long run it will cause more = harm than good. Regards, Christer =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 17. kes=E4kuuta 2007 12:53 > To: Keith Drage; IETF SIP List > Subject: Re: [Sip] INFO usage (or not) >=20 > How about this: >=20 > This document describes why the Session Initiation Protocol=20 > (SIP) INFO method, introduced in RFC 2976, has serious issues=20 > with any use outside its use as a transport mechanism for=20 > ISDN User Part (ISUP) call signaling in SIP-signaled=20 > networks. In the years since the introduction of the INFO=20 > method, the IETF has published numerous, interoperable=20 > extensions to SIP. > This document explains why there are INFO-based, proprietary=20 > protocols in the wild; the flaws of using INFO; and=20 > prescriptions for how to use existing, interoperable SIP=20 > mechanisms to accomplish most any of these tasks. >=20 >=20 > My personal preference is for the document to be Standards=20 > Track and be a Work Group chartered item. The reason is that=20 > for this document to be useful, it MUST update RFC 2976. If=20 > it updates RFC 2976, then newbies get the pointer when the=20 > download RFC 2976, pointing them to this document, before=20 > they go off, create draft-mumble-foo-over-INFO, and get=20 > flamed on the list. The essence of the normative content of=20 > the document is, "one MUST NOT use INFO for anything other=20 > than transporting ISUP or QSIG messages." >=20 > Because the normative content is so thin, I could understand=20 > not saying that and making the document Informational (or=20 > BCP). However, I really and truly believe that will=20 > significantly reduce the impact the document will have. >=20 >=20 > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt=20 > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate=20 > under what circumstances Update to RFC 2976 > - Limiting use of INFO to ISUP transport only Security Considerations >=20 >=20 >=20 >=20 >=20 > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > wrote: >=20 > > (As WG chair) > >=20 > > We have got a number of threads floating round on INFO=20 > usage, and it=20 > > would be nice to identify this into a potential body of=20 > work, and see=20 > > if there is support for it. > >=20 > > We have two previous drafts that never went anywhere, although=20 > > contents of both carried support in the WG at the time: > >=20 > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >=20 > > The Session Initiation Protocol (SIP) INFO method=20 > defines a means for > > transporting mid-dialog application layer data between=20 > user agents. > > Its initial use was to support the transport of ISUP mid-call > > messages which could not be mapped to any other SIP=20 > request method. > > However, since its initial usage for that purpose, INFO has seen > > widespread abuse as a means for introducing non-standard and > > non-interoperable extensions to SIP. For this reason,=20 > we now believe > > INFO should be considered harmful, and therefore,=20 > deprecated in its > > current form. > >=20 > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >=20 > > The SIP INFO method (RFC 2976) establishes a method by which > > applications may transfer application-specific=20 > information within a > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > describing and documenting an application of INFO, nor does it > > provide a mechanism by which applications may negotiate=20 > such uses. > > This document provides a framework for documenting and naming > > specific uses of INFO (called INFO packages), for=20 > registering those > > package names with IANA, and for negotiating the support=20 > for various > > INFO packages between applications using SIP. > >=20 > > In the thread so far there have also been suggestions that cover: > >=20 > > - support to mediactrl for their discussion on requirements > > - something for hitchhiker's guide to point to: > > - something that answers all the questions that recur on=20 > this list on=20 > > INFO usage > > - "I've been getting a lot of offline questions asking for=20 > the "right"=20 > > way to carry information related to the session-usage (often=20 > > information that's being tunneled around from companion or=20 > gatewayed=20 > > protocols)." > > - INVITE dialog usage only, or already covered by RFC 2976 > > - It would be OK with me if we ALSO had this type of=20 > guidance ("don't=20 > > look HERE, look over THERE") available ("stated strongly=20 > enough in an=20 > > easy to stumble across place"), but if coming up with that guidance=20 > > takes more than about a week, I don't see a lot of reason=20 > to hold up=20 > > on "don't go there" > > while we explore alternatives. > > - INFO and DTMF > > - XML payloads > > - But people really need is guidance on when to use INFO,=20 > when to use=20 > > events, and when to use something entirely different. > > - identification of purpose of info (Content-Type? - impacted by > > multipart/mixed) > > - any framework for control of usages (IANA registration? - RFC > > 3427 update) > >=20 > > Would anybody out there like to have a go at drafting an=20 > abstract for=20 > > a potential WG deliverable (and also identifying level - Info, BCP,=20 > > standards track) and submitting it to the list for discussion.=20 > > Remember an abstract needs to: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ------- > > Every RFC must have an Abstract section following the=20 > Copyright notice. > > An Abstract will typically be 5-10 lines. An Abstract of=20 > more than 20=20 > > lines is generally not acceptable. > >=20 > > The Abstract section should provide a concise and comprehensive=20 > > overview of the purpose and contents of the entire=20 > document, to give a=20 > > technically knowledgeable reader a general overview of the=20 > function of=20 > > the document. In addition to its function in the RFC itself, the=20 > > Abstract section text will appear in publication=20 > announcements and in=20 > > the online index of RFCs. > >=20 > > Composing a useful Abstract generally requires thought and care.=20 > > Usually an Abstract should begin with a phrase like "This=20 > memo ..." or=20 > > "This document ...". A satisfactory abstract can often be=20 > constructed=20 > > in part from material within the Introduction section, but a good=20 > > abstract will be shorter, less detailed, and perhaps=20 > broader in scope=20 > > than the Introduction. Simply copying and pasting the first few=20 > > paragraphs of the Introduction is tempting, but it may result in an=20 > > Abstract that is both incomplete and redundant. Note also that an=20 > > Abstract is not a substitute for an Introduction; the RFC should be=20 > > self-contained as if there were no Abstract section. > >=20 > > An Abstract should be complete in itself; it should not contain=20 > > citations unless they are completely defined within the Abstract. > > Abbreviations appearing in the Abstract should generally be=20 > expanded=20 > > in parentheses. There is a small set of reasonable=20 > exceptions to this=20 > > rule (see guidelines on abbreviations, above.) > >=20 > ---------------------------------------------------------------------- > > -- > > ------ > >=20 > > And as such should give a clear idea of whether there is=20 > anything we=20 > > should charter here or not. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 05:35:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DdU-00025V-0U; Mon, 18 Jun 2007 05:35:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0DdS-00025L-Jw for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DdS-00025C-9z for sip@ietf.org; Mon, 18 Jun 2007 05:34:58 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DdQ-0001hA-QG for sip@ietf.org; Mon, 18 Jun 2007 05:34:58 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5I9YsdN014665; Mon, 18 Jun 2007 11:34:55 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l5I9YscO002381; Mon, 18 Jun 2007 11:34:54 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:34:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 11:34:52 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A4075802149730@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP SAML Review by Erkki Koivusalo Thread-Index: Aces0fucrfmQnBbDRJiKX5ZPB1I70QAALFPwAAFEqdAAAGFKIAAB4FRwAAFeg9ABKVOToA== From: "Tschofenig, Hannes" To: "SIP IETF" X-OriginalArrivalTime: 18 Jun 2007 09:34:53.0956 (UTC) FILETIME=[ED15FC40:01C7B18B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [Sip] SIP SAML Review by Erkki Koivusalo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi all,=20 Here is a review by Erkki: =20 -----Urspr=FCngliche Nachricht----- Von: Koivusalo Erkki (Nokia-TP-MSW/Helsinki) = [mailto:Erkki.Koivusalo@nokia.com]=20 Gesendet: Dienstag, 12. Juni 2007 13:43 An: Tschofenig, Hannes Betreff: RE: [Sip] draft-ietf-sip-saml-02 Hi, Basically this is what I found before looking into the open issues list: --- As this draft reuses the mechanisms specified in RFC 4474 (more specifically the Identity-Info header) I am not sure=20 how implementations complying to RFC 4474 or this draft are able to interoperate. Is it straightforward for the recipient (UAS) of the=20 SIP request to find out whether the Identity-Info header contains an URL pointing to the certificate of the AS or the SAML assertion ? I assume the UAS finds it out only from the MIME type of the HTTP response, correct ?=20 Since the UAS verification steps of RFC 4474 and=20 draft-ietf-sip-saml differ from each other, what happens=20 if UAS supporting only RFC 4474 receives an Identity-Info=20 header pointing to a SAML assertion or vice versa ?=20 Can such an UAS gracefully handle the situation and if=20 yes, how ? @@ TODO: do we need to define a new SIP error response code for when a SAML assn signature is bad? e.g., '4xx Invalid SAML asssertion'. This TODO shall be resolved. To me an extra error code would make sense. 10. Verify that the SAML assertion contains an element, and that its value matches the value of the addr-spec of the SIP To header field. How is this matching to be done ? Shall the element exactly the SIP URI in the To header or can it contain just a part of it (like host part of the URI) ? The example in section 8 is like this: 19 20 example2.com 21 which is not a SIP URI, so I believe either the example or the normative text needs clarification. Nits: In section 6.1.2: Although this profile is overview is cast in terms of a SIP INVITE transaction The first 'is' of the sentence sounds unnecessary. and also containing a the domain's (example.com) public key = certificate The 'a' should be removed. The SIP URIs in Figure 2 should be checked: - Is Alice either Alice@example.com or alice@foo.com ? - Is Bob either bob@example.com or bob@example2.com ? - Should the SIP URIs of both Bob and Alice or neither of them have sip: prefix in the figure ? Currently Alice does not have it (in From) while Bob has (in To). In section 9.1.=20 * etc. This 'etc' should be removed.=20 ---- Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 05:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dqo-0001vO-FQ; Mon, 18 Jun 2007 05:48:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Dqm-0001ur-8D for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:48:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dql-0001ui-Tp for sip@ietf.org; Mon, 18 Jun 2007 05:48:43 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Dqk-0005lR-KZ for sip@ietf.org; Mon, 18 Jun 2007 05:48:43 -0400 X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1182160121!18057069!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 22828 invoked from network); 18 Jun 2007 09:48:41 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-5.tower-119.messagelabs.com with SMTP; 18 Jun 2007 09:48:41 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l5I9mfhl011002 for ; Mon, 18 Jun 2007 04:48:41 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5I9medj006326 for ; Mon, 18 Jun 2007 04:48:40 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5I9mcaj006316 for ; Mon, 18 Jun 2007 04:48:39 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Effect of SIP T1 timer value on T4 timer Date: Mon, 18 Jun 2007 17:48:36 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B04C2DEB9@ZMY16EXM66.ds.mot.com> In-Reply-To: <52a9bccc0706180102u246a9e11k7fa39374e8426aba@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Effect of SIP T1 timer value on T4 timer Thread-Index: Acexfx7/e/MN+aB/Rf+2c/pcML0KeQADl58Q X-Priority: 1 Priority: Urgent Importance: high References: <52a9bccc0706180102u246a9e11k7fa39374e8426aba@mail.gmail.com> From: "Avasarala Ranjit-A20990" To: "Jagan Mohan" , "SIP list" X-Vontu: Pass X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2129741420==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============2129741420== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B18D.D7FEC576" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B18D.D7FEC576 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jagan =20 Timer T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value for T4 is 5 seconds. Also T4 is a constant and not set based on T1. For more details refer to Sec 17.1.2.2 of RFC 3261. =20 Regards=20 Ranjit=20 =20 ________________________________ From: Jagan Mohan [mailto:jaganmk@gmail.com]=20 Sent: Monday, June 18, 2007 1:33 PM To: SIP list Subject: [Sip] Effect of SIP T1 timer value on T4 timer Hi, I would like to how T4 timer needs to be set, based on the value of T1? If round trip delay is, say 20s, then T1 needs to be set to 20s. To what value should T4 timer, needs to be set now? Should T4 needs to be set as (Actual value of T1)*(default value of T4/ default value of T1)? If yes, could you please explain the logic behind this.=20 Thanks, Jagan =20 ------_=_NextPart_001_01C7B18D.D7FEC576 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Jagan
 
Timer=20 T4 represents the amount of time the network will take to clear messages = between=20 client and server transactions. The default value for T4 is 5 seconds. = Also T4=20 is a constant and not set based on T1. For more details refer to Sec = 17.1.2.2 of=20 RFC 3261.
 
Regards
Ranjit
 

From: Jagan Mohan = [mailto:jaganmk@gmail.com]=20
Sent: Monday, June 18, 2007 1:33 PM
To: SIP=20 list
Subject: [Sip] Effect of SIP T1 timer value on T4=20 timer

Hi,

   I would like to how T4 timer needs to = be set,=20 based on the value of T1?
If round trip delay is, say 20s, then T1 = needs to=20 be set to 20s. To what value should T4 timer, needs to be set=20 now? Should T4 needs to be set as (Actual value of=20 T1)*(default value of T4/ default value of T1)? If yes, could you please = explain=20 the logic behind this.

Thanks,
Jagan
 
------_=_NextPart_001_01C7B18D.D7FEC576-- --===============2129741420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2129741420==-- From sip-bounces@ietf.org Mon Jun 18 09:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GzV-0005o5-Ds; Mon, 18 Jun 2007 09:09:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0GzT-0005ny-56 for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 09:09:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0GzS-0005nq-Rn for sip@ietf.org; Mon, 18 Jun 2007 09:09:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0GzQ-00070t-Qv for sip@ietf.org; Mon, 18 Jun 2007 09:09:54 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1289121ugf for ; Mon, 18 Jun 2007 06:09:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=VHH0KP9CiEHwAto613FsdZG/zx87c1BAoevGkSCS7I28NTbccYezR90xKR/DoJ/8dtXMxg0+SasiNxv375yWAUa56xFNJB4IztiL+LmmYNixzPJ9ELdRsBy97rJyfJYroWuWsM3qWzikxWp+9i4pT2sXXJUNODXAPE2TG+8MZTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DTUQmOUORrJPGBe6Et1zetlmMXS11weiTmAw8OCHukVvvK9+vAsvMCTb1mOaMH/hSIBA5D+38lmEOr+L5WqHCNwCdcMl+5lIOYu72S1sXh6TO5egPtho+OHgejXRBuZ/S5EusZUfZYZgMc5BhZMx8I3PlmsM7jaOMZFu6eB0ng8= Received: by 10.66.222.9 with SMTP id u9mr2895696ugg.1182172192170; Mon, 18 Jun 2007 06:09:52 -0700 (PDT) Received: by 10.67.86.16 with HTTP; Mon, 18 Jun 2007 06:09:52 -0700 (PDT) Message-ID: <52a9bccc0706180609s792204e4vd216960a0cf427c9@mail.gmail.com> Date: Mon, 18 Jun 2007 18:39:52 +0530 From: "Jagan Mohan" To: "Avasarala Ranjit-A20990" Subject: Re: [Sip] Effect of SIP T1 timer value on T4 timer In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B04C2DEB9@ZMY16EXM66.ds.mot.com> MIME-Version: 1.0 References: <52a9bccc0706180102u246a9e11k7fa39374e8426aba@mail.gmail.com> <750BBC72E178114F9DC4872EBFF29A5B04C2DEB9@ZMY16EXM66.ds.mot.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: SIP list X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699228672==" Errors-To: sip-bounces@ietf.org --===============1699228672== Content-Type: multipart/alternative; boundary="----=_Part_71689_3675114.1182172192140" ------=_Part_71689_3675114.1182172192140 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ranjit, Thanks for replying. I haven't completely understood the definition of T4 timer. Could you please explain it? Thanks, Jagan On 6/18/07, Avasarala Ranjit-A20990 wrote: > > Hi Jagan > > Timer T4 represents the amount of time the network will take to clear > messages between client and server transactions. The default value for T4 is > 5 seconds. Also T4 is a constant and not set based on T1. For more details > refer to Sec 17.1.2.2 of RFC 3261. > ** > *Regards* > *Ranjit * > > > ------------------------------ > *From:* Jagan Mohan [mailto:jaganmk@gmail.com] > *Sent:* Monday, June 18, 2007 1:33 PM > *To:* SIP list > *Subject:* [Sip] Effect of SIP T1 timer value on T4 timer > > Hi, > > I would like to how T4 timer needs to be set, based on the value of T1? > If round trip delay is, say 20s, then T1 needs to be set to 20s. To what > value should T4 timer, needs to be set now? Should T4 needs to be > set as (Actual value of T1)*(default value of T4/ default value of T1)? If > yes, could you please explain the logic behind this. > > Thanks, > Jagan > > ------=_Part_71689_3675114.1182172192140 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ranjit,
    
    Thanks for replying.

    I haven't completely understood the definition of T4 timer. Could you please explain it?

Thanks,
Jagan

On 6/18/07, Avasarala Ranjit-A20990 <ranjit@motorola.com> wrote:
Hi Jagan
 
Timer T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value for T4 is 5 seconds. Also T4 is a constant and not set based on T1. For more details refer to Sec 17.1.2.2 of RFC 3261.
 
Regards
Ranjit
 

From: Jagan Mohan [mailto:jaganmk@gmail.com]
Sent: Monday, June 18, 2007 1:33 PM
To: SIP list
Subject: [Sip] Effect of SIP T1 timer value on T4 timer

Hi,

   I would like to how T4 timer needs to be set, based on the value of T1?
If round trip delay is, say 20s, then T1 needs to be set to 20s. To what value should T4 timer, needs to be set now? Should T4 needs to be set as (Actual value of T1)*(default value of T4/ default value of T1)? If yes, could you please explain the logic behind this.

Thanks,
Jagan
 

------=_Part_71689_3675114.1182172192140-- --===============1699228672== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1699228672==-- From sip-bounces@ietf.org Mon Jun 18 10:17:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I2O-0004od-A4; Mon, 18 Jun 2007 10:17:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0I2N-0004oV-49 for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 10:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0I2M-0004oN-QX for sip@ietf.org; Mon, 18 Jun 2007 10:16:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0I2L-0003jH-5S for sip@ietf.org; Mon, 18 Jun 2007 10:16:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jun 2007 10:16:58 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="123899153:sNHT72681142" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5IEGu3R008880; Mon, 18 Jun 2007 10:16:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5IEGk67008347; Mon, 18 Jun 2007 14:16:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:16:46 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:16:46 -0400 Message-ID: <467693CD.1040206@cisco.com> Date: Mon, 18 Jun 2007 10:16:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 14:16:46.0052 (UTC) FILETIME=[4D7B0A40:01C7B1B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10722; t=1182176216; x=1183040216; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20 |To:=20Eric=20Burger=20; bh=wL9CU0W8M611waQe4oO6A3lgXjp4XyzvI+B8ffZ19rM=; b=EPmTgjoUgD/n4+g2oBxqSRE4I8cFGJ2zV5u/EdEZ5Qx5NXzdzC/am7aY8EMiHoUVJaT3APw9 iD47NGgYMcTTa3GkVpB64sdXtGx6C1GWbM2DncUUb2755vpK6GlSFih9; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: sip@ietf.org, Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > :-) I hate it too - not in the abstract, but in the way it has become the solution to all problems. IMO it is ok as an extensible, interoperable, program-to-program representation of complex structured data. But it is not a programming language, or suitable as a user interface, and people should not have to write it. > Going a step further: if SIP goes beyond the standard MIME processing, I > would offer that rather than use the hammer of the 1990's (MIME), we move to > the hammer of the 2000's (XML). Perhaps if we were starting off to do SIP/3.0 (no I'm not suggesting that we do that), it might make sense to use XML rather than MIME. Given where we are, I don't think it makes sense to use XML rather than MIME to represent multiple independent body parts in a request. We are *already* defining most new body parts in XML, and making them extensible so that they can contain other XML things. But I wouldn't go out of my way to start redefining mime-type as XML just so they can be incorporated into other XML things. Paul > :-)) > > > > On 5/30/07 4:53 AM, "Gonzalo Camarillo" > wrote: > >> Hi, >> >> what Keith says makes sense. I believe mandating support for multipart >> in SIP is a SIP-specific problem. Mandating suppport for >> multipart/alternative is also a SIP-specific problem, since a >> SIP-specific problem such as the transition to new session description >> formats depends on that. >> >> However, specifying if an implementation that supports multipart should >> support nested body parts or not is something more general on which the >> email folks have a lot of experience. >> >> Cheers, >> >> Gonzalo >> >> >> DRAGE, Keith (Keith) wrote: >>> Well, at the moment, what I am trying to do is get some understanding of >>> what we should scope as valid SIP work. >>> >>> We need to be able to understand why something that is clearly a generic >>> problem for specification of nested MIME bodies merits a SIP specific >>> solution. >>> >>> So: >>> >>> - is a generic solution already documented elsewhere? >>> >>> - if a generic solution is not documented elsewhere, should one be >>> documented, rather than a specific SIP solution? >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Christer Holmberg (JO/LMF) >>>> [mailto:christer.holmberg@ericsson.com] >>>> Sent: Wednesday, May 30, 2007 8:52 AM >>>> To: DRAGE, Keith (Keith); Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>>> Cc: sip@ietf.org >>>> Subject: RE: [Sip] MIME: Nested bodies with option-tag? >>>> >>>> >>>> Hi Keith, >>>> >>>>> Once we get down to a decision of supporting nested versus not >>>>> supporting nesting, presumably we are then entirely in the >>>> realm of the >>>>> multipart coding itself. >>>>> >>>>> Could I ask someone to elaborate on what generic >>>> requirements already >>>>> exist within multipart/mime in this respect, before we start >>>> looking at >>>>> defining SIP specific rules or indications? >>>> I am very sure that I have seen text related to the support >>>> of nested multiparts, and what nodes are expected to support, >>>> somewhere, but I yet have not found it. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Christer Holmberg (JO/LMF) >>>>>> [mailto:christer.holmberg@ericsson.com] >>>>>> Sent: Tuesday, May 29, 2007 2:47 PM >>>>>> To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat >>>>>> Cc: sip@ietf.org >>>>>> Subject: RE: [Sip] MIME: Nested bodies with option-tag? >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> My main concern is not what wording (SHALL, MUST, etc) we use. >>>>>> >>>>>> The issue is that I think we need text saying what >>>> implementations >>>>>> that DO NOT support alternative and/or nested shall do. If >>>>> we say that >>>>>> they shall reject the message I believe that many of the existing >>>>>> implementations will be compliant with the spec. >>>>>> >>>>>> And, if we give the possibility to simply reject the message, I >>>>>> believe it will be easier to get people to change their >>>>>> implementations, if they currently simply discard >>>>> alternative and/or >>>>>> nested today. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>>>>>> Sent: 29. toukokuuta 2007 16:06 >>>>>>> To: Paul Kyzivat >>>>>>> Cc: Christer Holmberg (JO/LMF); sip@ietf.org >>>>>>> Subject: Re: [Sip] MIME: Nested bodies with option-tag? >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> what I am hearing is that there are implementations out >>>>> there that >>>>>>> support multipart but not nested. Therefore, we need to >>>> decide two >>>>>>> things: >>>>>>> >>>>>>> 1) do we want to have a MUST for multipart and a SHOULD for >>>>>> nested? I >>>>>>> would say that we should have the same level (e.g., MUST, if we >>>>>>> decided that MUST is appropriate) for both. >>>>>>> >>>>>>> 2) do we need a way for implementations that support >>>>>> multipart but not >>>>>>> nested to be quickly updated to, at least, report that >>>>> fact with an >>>>>>> error response? This may make sense. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>>> More or less repeating what I said before: >>>>>>>> >>>>>>>> I expect we do have to account in some way for >>>>>> implementations that >>>>>>>> have already been deployed, in absence of a >>>> clarifying document. >>>>>>>> Exactly how we deal with that is still TBD. >>>>>>>> >>>>>>>> But as we define what is required to support this in the >>>>>> future, I >>>>>>>> think there is *no* benefit to defining two levels of >>>>>>> support - full >>>>>>>> and partial. Anybody that sets out to provide support >>>> for this >>>>>>>> document should be expected to do it all - its not that >>>>>> much harder. >>>>>>>> Paul >>>>>>>> >>>>>>>> Christer Holmberg (JO/LMF) wrote: >>>>>>>>> Hi, >>>>>>>>>> I wonder whether we should define an option-tag for the >>>>>>> support of >>>>>>>>>> nested bodies. >>>>>>>>>> >>>>>>>>>> I don't think there's a lot to be gained from >>>>> defining such an >>>>>>>>>> option-tag. The sender should already be aware that >>>>>>> there is a risk >>>>>>>>>> the recipient can't understand nested bodies, and have >>>>>>> arranged for >>>>>>>>>> suitable fallbacks. Conversely, the recipient should (at >>>>>>> least) be >>>>>>>>>> able to skip the nested multipart body part in the proper >>>>>>> "I don't >>>>>>>>>> understand this body part" way. All an option-tag would >>>>>>> do is allow >>>>>>>>>> the sender to not add a fallback. >>>>>>>>> In that case we need some specific text saying that if the >>>>>>> receiver >>>>>>>>> does not support nested multiparts it MUST >>>> do-this-and-do-that. >>>>>>>>> Because, as I said earlier, I don't think we will >>>>>> achieve what we >>>>>>>>> want by saying that one MUST be able to parse nested >>>>>>> multiparts. It >>>>>>>>> can be rather tricky to implement (depending on how the >>>>>> parser is >>>>>>>>> implemented, though), and since there aren't really any >>>>>>> use-cases out >>>>>>>>> there yet I am pretty sure some people will choose not to >>>>>>> implement >>>>>>>>> it (and saying that people are not compliant in that >>>>>> case will not >>>>>>>>> really help from an interop perspective). So, because of >>>>>>> that I think >>>>>>>>> it would be good not to mandate the support of nested >>>>>>> multiparts, but >>>>>>>>> to mandate appropriate behavior if not supported - just >>>>>>> like in any >>>>>>>>> other case when a MIME body contains an unsupported but >>>>>>> required content type. >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>>> This list is for NEW development of the core SIP >>>> Protocol Use >>>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>>> current sip Use >>>>>>>>>> sipping@ietf.org for new developments on the >>>>> application of sip >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>>> This list is for NEW development of the core SIP >>>> Protocol Use >>>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>>> current sip Use >>>>>>>>> sipping@ietf.org for new developments on the >>>> application of sip >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>>>> sip-implementors@cs.columbia.edu for questions on >>>>> current sip Use >>>>>>>> sipping@ietf.org for new developments on the >>>> application of sip >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 10:46:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IVI-00055o-JP; Mon, 18 Jun 2007 10:46:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0IVG-00055h-FA for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 10:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IVG-00055Z-5X for sip@ietf.org; Mon, 18 Jun 2007 10:46:50 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IVE-0003XF-RG for sip@ietf.org; Mon, 18 Jun 2007 10:46:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5IEklNP017998; Mon, 18 Jun 2007 09:46:47 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5IEkla05759; Mon, 18 Jun 2007 09:46:47 -0500 (CDT) Message-ID: <46769AD7.8010606@alcatel-lucent.com> Date: Mon, 18 Jun 2007 09:46:47 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> In-Reply-To: <4672F349.8000203@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I like the direction this is headed. I have a few questions and > observations: Paul: Thanks much for reading the draft. More inline. > There seem to be some constraints for support of sipsec that I didn't > see mentioned explicitly: - The UAC and each proxy must ensure that > the transport used for the next hop is a connection-oriented, > congestion-controlled transport. That is mentioned in the overview, > but not specifically for the UAC and Proxy. Right; modeling it on HTTP implicitly implied a congestion-controlled transport. With DTLS now in mix, one could conceivably consider using a connectionless transport with similar security properties as well. But at least right now, we're only considering congestion controlled transports. > - For the tunneling to work I don't think there can be shared use of > the connection. That is something special here. (In case of SCTP, I > guess it would be sufficient to reserve a stream.) Right; in the default case, since the properties of the connection are tied to the certificates of the endpoints at each side, sharing a connection would appear to be problematic. Now, one use case for sharing could be a pair of user agents that serve a lot of users (gateways, for instance.) One could conceivably consider requests for different ports to be sent over the same tunnel. But this is not a specific scenario we had envisioned as a reason for the draft. > There are some things that is is desirable to do that may be hard > with sipsec, or at least need to be figured out. A couple that come > to mind are: > - best effort security > - forking > For best effort security, one option seems to be to delay the CONNECT > until you know the capabilities of the callee. For instance, a > session could be established with SIP or SIPS, including > supported:sipsec. If the session is established, then it could be > followed up with a CONNECT/Replaces. The problem with this approach would be that privacy is violated in the session that is established before the CONNECT request; even when h-b-h sips is used. > If you want to call an AOR that results in forking, CONNECT doesn't > seem to work very well. I This may be a good reason to replace > forking at a proxy with redirect. The proxy could return 3xx with the > alternatives, which might be either SIP, SIPS, or SIPSEC. There are a > lot of details to work our for this. Right; agree. Forking is problematic. One way is to force the issue with rfc3841's Request-Disposition header. But that header elicits a normative strength of SHOULD in the proxies, thereby lending it an advisory mode only. Another way is to discourage forking for CONNECT in the draft, but allow for it to occur and simply accept the first 200 OK, closing the connection on subsequent ones. Clearly something that needs to be worked out in the draft going forward. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 11:12:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ItX-0006Sv-Mx; Mon, 18 Jun 2007 11:11:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ItW-0006Sh-2X for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ItV-0006SA-Oj for sip@ietf.org; Mon, 18 Jun 2007 11:11:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ItV-0002CX-9S for sip@ietf.org; Mon, 18 Jun 2007 11:11:53 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jun 2007 11:11:50 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="123905760:sNHT64506782" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IFBnZP022170; Mon, 18 Jun 2007 11:11:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5IFBPCC000149; Mon, 18 Jun 2007 15:11:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:11:44 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:11:43 -0400 Message-ID: <4676A0AE.2000206@cisco.com> Date: Mon, 18 Jun 2007 11:11:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] MIME: Nested bodies with option-tag? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 15:11:43.0659 (UTC) FILETIME=[FB01EFB0:01C7B1BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5621; t=1182179509; x=1183043509; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20MIME=3A=20Nested=20bodies=20with=20option-tag ? |Sender:=20 |To:=20Eric=20Burger=20; bh=RfzByrocQaKvXJZ2UL5aocZ3rG5nyOxo4bU3425hkWU=; b=HyfHqjZHJBNN83GqEFjF8WiZV/NhURrS7QjF30M0fAtJ6kOFx3yNJ5EFEguAer0jeMexqNVZ sjzL690Kd0jSukP67Lp/lsKh8ZTH0nwUOGQW+pPxUJ211e/8SuQS2C6l; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric, I don't understand how to apply this to sip. 3459 defines the criterion for REQUIRED as: If the content gateway cannot pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action. That makes sense for a mail gateway. (I don't know if it makes sense for a mail user agent.) But attempting to apply it to sip still leaves a lot of questions. In particular, I can see that in a mail message the multipart bodies themselves are actually rendered in the sense that they are shown as nested containers. In sip, in general that won't be the case - much of the content won't be "rendered", though it may be "processed" in some sense. Unless we define what we mean by "processing" then I think we haven't finished. Consider a few cases: 1. content-type SDP, content-disposition session;handling=required We know what that means, if in a message where an offer or answer is allowed, or a preview of an offer or answer, or in an OPTIONS response. We don't have a meaning for this in other contexts, such as SUBSCRIBE, NOTIFY, MESSAGE or their responses. If you were to receive the body in one of those, what should be done? Should that be a 415 response? 2. content-type text/plain, content-disposition render;handling=required We know what this means in MESSAGE. What should be done in other requests, or in responses? 3. c-t multipart/mixed, c-d ???;handling=required c-t SDP, c-d session;handling=required c-t application/ISUP, c-d signal;handling=optional I think this should be legal all the same places where (1) is legal. But a recipient that doesn't understand multipart/mixed will return a 415. I don't know what the content-disposition should be for the multipart. I guess for mail the default of render works, because it can really be rendered. That doesn't make sense for sip in this case. I have never seen an example using a multipart/mixed that included a content-disposition for it. AFAIK the default should be "render;handling=required". But for sip I don't know what it means to "render" a multipart. 4. c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is a little silly, but seems legal. If you can handle (3) then you should be able to handle this. Somebody that doesn't handle the multipart would return 415. 5. c-t multipart/mixed; c-d ???;handling=required c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is even sillier. But it raises more issues. If you handle (4), must you also handle this? If it is acceptable to handle (4) and not handle this, then what response should there be? AFAIK these are questions about the application of MIME to sip, that don't seem to have been handled by the mail work because the issues just didn't come up there. Thanks, Paul Eric Burger wrote: > Correct. That is the mechanism specified by RFC 3459. > > > On 6/3/07 6:47 PM, "Dale.Worley@comcast.net" > wrote: > >> From: "DRAGE, Keith \(Keith\)" >> >> Well, at the moment, what I am trying to do is get some understanding of >> what we should scope as valid SIP work. >> >> I've been busy, so I may be behind in the discussion, but it's not >> clear to me that there is anything that needs to be done specifically >> for SIP. I may well be wrong, but my impression is that MIME already >> has the features and specifications neede so that a receiver can >> decide whether it has adequately "understood" the document when it >> only understands some components. These mechanisms are all inherited >> by SIP and I would expect be a sufficient set of rules. >> >> E.g., a UAC that sends a request with a multipart body must expect >> that some UASs will respond with 415, and have some strategy in place >> for dealing with that situation. Similarly, a UAC that sends a nested >> multipart body must expect that some UASs will be unable to process >> the nested multipart, and will either ignore it or reject the request >> (as specified), and the UAC must be prepared to deal with that >> situation. >> >> Is there a reason we need to define new, narrower subsets of allowed >> behaviors and define a SIP mechanism to negotiate these? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 11:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JRY-0007Qy-3v; Mon, 18 Jun 2007 11:47:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0JRW-0007L0-Bm for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JRW-0007KV-1R for sip@ietf.org; Mon, 18 Jun 2007 11:47:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0JRV-0007xp-MV for sip@ietf.org; Mon, 18 Jun 2007 11:47:02 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Jun 2007 11:47:01 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="123909932:sNHT61523928" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5IFl19B024425; Mon, 18 Jun 2007 11:47:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5IFkq5p004163; Mon, 18 Jun 2007 15:46:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:46:56 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:46:56 -0400 Message-ID: <4676A8EF.4000309@cisco.com> Date: Mon, 18 Jun 2007 11:46:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] SIP-body-handling Open Issue 3 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 15:46:56.0532 (UTC) FILETIME=[E660C540:01C7B1BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3622; t=1182181621; x=1183045621; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20SIP-body-handling=20Open=20Issue=203 |Sender:=20 |To:=20Eric=20Burger=20; bh=rXb5krzoi61e0ZsMmk9xu3xtESxPmgnj/Wjoap4q+Ms=; b=fbADAXR50OBzRiKRo+PA3M3NMGGXdoT8ZJPtSRT6HxWwFqyhUmUP87yIP7At8uzx1KeezYFj gaKcltfQjo/PD72e9nX7SF50UBSgGcEMDUB0y1nEmAVLlRQNnqVtdcUf; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: sip@ietf.org, Gonzalo Camarillo X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Eric Burger wrote: > I do not think one can say what the Content-Disposition of a multipart/* > body part should be. From RFC 2183: > > If a Content-Disposition header is used on a multipart body part, it > applies to the multipart as a whole, not the individual subparts. > The disposition types of the subparts do not need to be consulted > until the multipart itself is presented. When the multipart is > displayed, then the dispositions of the subparts should be respected. I've been looking for somebody who understands how this was intended to work in MIME. I guess you are that somebody. The quote above starts with an "if". That makes sense for multipart/alternative. But what about a multipart/mixed where the individual subparts have different dispositions? We need some content disposition that results in the subparts being investigated in an appropriate way. But what would that be for sip? > We already have a compatible-with-MIME solution. Mark the > Content-Disposition of the multipart/* as render, session, or inline with > the needed handling parameter, and have the Content-Disposition of the > sub-parts be whatever they really need to be (if not render). The logic is > simply to say what you mean. Consider the SDP+ISUP case. The sdp disposition is "session" and the ISUP disposition is "signal". What should the disposition of the multipart be? In the case of mail it seems that "render" works, because the multipart itself can be rendered. But that doesn't make sense for sip. > It really is just a suggestion. If we are > talking about a multipart/alternative describing sessions, then the > Content-Disposition should be session. Of course, you could have > Content-Disposition be foobar (or, better yet, inline), so long as (1) the > UAS does not barf and (2) the real Content-Dispositions are present on all > of the sub-parts. I don't fully know what "inline" means. If we interpreted it to mean "inline with the sip processing" then it would be reasonable. As best I understand it, any part that does not have its own content-disposition header has a default that is determined in a context-free way, (the default disposition for content-type application/sdp is "session" and the for application/isup is "signal") and the default-default is "render". I haven't seen any indication that the content-disposition is ever inherited from the enclosing body. So, unless I've missed something, the default disposition for multipart/* is "render". But unless we define what it means to "render" a multipart in sip then I think this is nonsense. It may be that for reasons of backward compatibility we should define "render" for sip, at least for multipart. But that would be a bit ugly. Paul > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K6k-0007Xy-7o; Mon, 18 Jun 2007 12:29:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0K6i-0007Rf-0J for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K6h-0007Q0-MV for sip@ietf.org; Mon, 18 Jun 2007 12:29:35 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0K6g-0000P7-Bs for sip@ietf.org; Mon, 18 Jun 2007 12:29:35 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5IGTUH10629; Mon, 18 Jun 2007 16:29:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Mon, 18 Jun 2007 11:29:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A7F6@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: AcewW2SpVTKi8u94Rj+HJ49l8Z+TqgBabfNQ References: From: "Francois Audet" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi James, It might be useful to have some wording on the limitations of using a response to carry a Resource-Priority header in a response. Specifically, a UAS can not use a response to carry the Resource-Priority in cases where the Resource-Priority "absolutely has" to be delivered to the=20 UAC. It is therefore only useable for cases where a forking proxy=20 may discard the response (i.e., forward another instead) without breaking anything. In other words,you need to think about HEFP before using this draft. In some scenarios, this is probably the desired behavior. In other scenarios, it may not acceptable. So instead, for those scenarios, the terminating side would have to send a new request with a Resource-Priority=20 instead of using a response. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Saturday, June 16, 2007 14:14 > To: sip@ietf.org > Subject: [Sip] New draft modifying RFC 4412 for Responses >=20 > SIP WG >=20 > Here is a new ID I've written because of implementation=20 > considerations to allow a SIP Resource-Priority header (RPH)=20 > in responses, which RFC 4412 currently disallows, assuming=20 > only that stateful devices will use RPH. There have been=20 > many requests to have this "only stateful devices"=20 > restriction relaxed, in certain scenarios. This ID does=20 > this, and proposes how IANA is changed accordingly wrt RPH. =20 > This ID does nothing else. >=20 > Comments are appreciated. >=20 > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > > > Title : Allowing SIP Resource Priority Header in=20 > > SIP Responses > > Author(s) : J. Polk > > Filename : draft-polk-sip-rph-in-responses-00.txt > > Pages : 6 > > Date : 2007-6-15 > > > > The Session Initiation Protocol (SIP) Resource Priority Header > > (RPH), in its current form, is ignored in SIP responses.=20 > This was a > > design choice during RFC 4412's development. This is now=20 > considered > > a bad design choice in certain scenarios. This document corrects > > RFC 4412's communications model by optionally allowing a=20 > SIP server > > or user agent client to process the Resource-Priority Header in a > > response. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-res > ponses-00. > >txt >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KC1-0007Hf-Ox; Mon, 18 Jun 2007 12:35:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KC0-0007B9-0Q for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KBz-000793-Ls for sip@ietf.org; Mon, 18 Jun 2007 12:35:03 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KBx-0001eD-Bj for sip@ietf.org; Mon, 18 Jun 2007 12:35:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5IGYwI07238; Mon, 18 Jun 2007 16:34:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO and ISUP Date: Mon, 18 Jun 2007 11:34:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A81F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and ISUP Thread-Index: AcexNfesNm477B0pEdy0uwAWy4mm/wAkFlCA References: From: "Francois Audet" To: "Eric Burger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Actually, it's not just ISUP. It's also QSIG. But I agree, INFO was supposed to be be used only for tunnelling legacy PSTN protocols between Media Gateway=20 Controllers.=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Sunday, June 17, 2007 02:20 > To: sip@ietf.org > Subject: [Sip] INFO and ISUP >=20 > I cringe every time someone says, "The only acceptable use=20 > for INFO is for ISUP." ALL of the arguments that apply to=20 > "One cannot use INFO for foo" > apply to why "One cannot use INFO for ISUP." >=20 > The INFO method is NOT to "carry [arbitrary] mid-session=20 > information between SIP user agents" as RFC 2976 posits. The=20 > one and only one reason one can use INFO for ISUP today is=20 > because the method is ONLY defined for ISUP. >=20 > Said another way: the identifier 0x49 0x4E 0x46 0x4F has=20 > *NOTHING* to do with INFO. It would have much better been=20 > called 0x4E 0x53 0x55 0x50 (ISUP). >=20 > For legacy reasons, and because we really are talking about a=20 > bunch of bits, not English, I would not offer we change the=20 > name of the method. However, I would make it clear that the=20 > method is NOT the general purpose method described in RFC 2976. >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:45:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KMK-0007KI-NG; Mon, 18 Jun 2007 12:45:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KMJ-0007K3-AS for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KMJ-0007Jv-0u for sip@ietf.org; Mon, 18 Jun 2007 12:45:43 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KMG-0003pS-FU for sip@ietf.org; Mon, 18 Jun 2007 12:45:43 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5IGjctd031789; Mon, 18 Jun 2007 09:45:38 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5IGibXY009888; Mon, 18 Jun 2007 09:45:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Sip] SIP-body-handling Open Issue 3 Date: Mon, 18 Jun 2007 09:45:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIP-body-handling Open Issue 3 Thread-Index: Acexv+1MBU3PvZe/RtW7V5UtR4LuBwACCkRr From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org All the standard says is the content-disposition is inherited from the outer multipart. If you want a different disposition for a subpart, you mark it appropriately. In your examples, you would mark the SDP session and the ISUP signal. You could get away with marking the multipart as session, be silent on the SDP, and mark the ISUP as signal. I would offer we recommend UAC's mark all body parts. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Paul Kyzivat To: Eric Burger CC: Gonzalo Camarillo ; sip@ietf.org Sent: Mon Jun 18 08:46:55 2007 Subject: Re: [Sip] SIP-body-handling Open Issue 3 Eric Burger wrote: > I do not think one can say what the Content-Disposition of a multipart/* > body part should be. From RFC 2183: > > If a Content-Disposition header is used on a multipart body part, it > applies to the multipart as a whole, not the individual subparts. > The disposition types of the subparts do not need to be consulted > until the multipart itself is presented. When the multipart is > displayed, then the dispositions of the subparts should be respected. I've been looking for somebody who understands how this was intended to work in MIME. I guess you are that somebody. The quote above starts with an "if". That makes sense for multipart/alternative. But what about a multipart/mixed where the individual subparts have different dispositions? We need some content disposition that results in the subparts being investigated in an appropriate way. But what would that be for sip? > We already have a compatible-with-MIME solution. Mark the > Content-Disposition of the multipart/* as render, session, or inline with > the needed handling parameter, and have the Content-Disposition of the > sub-parts be whatever they really need to be (if not render). The logic is > simply to say what you mean. Consider the SDP+ISUP case. The sdp disposition is "session" and the ISUP disposition is "signal". What should the disposition of the multipart be? In the case of mail it seems that "render" works, because the multipart itself can be rendered. But that doesn't make sense for sip. > It really is just a suggestion. If we are > talking about a multipart/alternative describing sessions, then the > Content-Disposition should be session. Of course, you could have > Content-Disposition be foobar (or, better yet, inline), so long as (1) the > UAS does not barf and (2) the real Content-Dispositions are present on all > of the sub-parts. I don't fully know what "inline" means. If we interpreted it to mean "inline with the sip processing" then it would be reasonable. As best I understand it, any part that does not have its own content-disposition header has a default that is determined in a context-free way, (the default disposition for content-type application/sdp is "session" and the for application/isup is "signal") and the default-default is "render". I haven't seen any indication that the content-disposition is ever inherited from the enclosing body. So, unless I've missed something, the default disposition for multipart/* is "render". But unless we define what it means to "render" a multipart in sip then I think this is nonsense. It may be that for reasons of backward compatibility we should define "render" for sip, at least for multipart. But that would be a bit ugly. Paul > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KOy-0007mz-AP; Mon, 18 Jun 2007 12:48:28 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KOw-0007ms-Qs for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:48:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KOw-0007mf-Gx for sip@ietf.org; Mon, 18 Jun 2007 12:48:26 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KOu-0004SU-1g for sip@ietf.org; Mon, 18 Jun 2007 12:48:26 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5IGmLb25068; Mon, 18 Jun 2007 16:48:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Mon, 18 Jun 2007 11:48:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A86E@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wAjLcIQ References: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: "Eric Burger" , "Keith Drage" , "IETF SIP List" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org My preference would be to restrict the use of INFO to supporting legacy PSTN protocols. We could even restrict it to the ones in=20 RFC 3204. In other words, let's just cap it. And yes, I'd say Standards track that updates RFC 2976. > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Sunday, June 17, 2007 02:53 > To: Keith Drage; IETF SIP List > Subject: Re: [Sip] INFO usage (or not) >=20 > How about this: >=20 > This document describes why the Session Initiation Protocol=20 > (SIP) INFO method, introduced in RFC 2976, has serious issues=20 > with any use outside its use as a transport mechanism for=20 > ISDN User Part (ISUP) call signaling in SIP-signaled=20 > networks. In the years since the introduction of the INFO=20 > method, the IETF has published numerous, interoperable=20 > extensions to SIP. > This document explains why there are INFO-based, proprietary=20 > protocols in the wild; the flaws of using INFO; and=20 > prescriptions for how to use existing, interoperable SIP=20 > mechanisms to accomplish most any of these tasks. >=20 >=20 > My personal preference is for the document to be Standards=20 > Track and be a Work Group chartered item. The reason is that=20 > for this document to be useful, it MUST update RFC 2976. If=20 > it updates RFC 2976, then newbies get the pointer when the=20 > download RFC 2976, pointing them to this document, before=20 > they go off, create draft-mumble-foo-over-INFO, and get=20 > flamed on the list. The essence of the normative content of=20 > the document is, "one MUST NOT use INFO for anything other=20 > than transporting ISUP or QSIG messages." >=20 > Because the normative content is so thin, I could understand=20 > not saying that and making the document Informational (or=20 > BCP). However, I really and truly believe that will=20 > significantly reduce the impact the document will have. >=20 >=20 > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt=20 > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate=20 > under what circumstances Update to RFC 2976 > - Limiting use of INFO to ISUP transport only Security Considerations >=20 >=20 >=20 >=20 >=20 > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > wrote: >=20 > > (As WG chair) > >=20 > > We have got a number of threads floating round on INFO=20 > usage, and it=20 > > would be nice to identify this into a potential body of=20 > work, and see=20 > > if there is support for it. > >=20 > > We have two previous drafts that never went anywhere, although=20 > > contents of both carried support in the WG at the time: > >=20 > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >=20 > > The Session Initiation Protocol (SIP) INFO method=20 > defines a means for > > transporting mid-dialog application layer data between=20 > user agents. > > Its initial use was to support the transport of ISUP mid-call > > messages which could not be mapped to any other SIP=20 > request method. > > However, since its initial usage for that purpose, INFO has seen > > widespread abuse as a means for introducing non-standard and > > non-interoperable extensions to SIP. For this reason,=20 > we now believe > > INFO should be considered harmful, and therefore,=20 > deprecated in its > > current form. > >=20 > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >=20 > > The SIP INFO method (RFC 2976) establishes a method by which > > applications may transfer application-specific=20 > information within a > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > describing and documenting an application of INFO, nor does it > > provide a mechanism by which applications may negotiate=20 > such uses. > > This document provides a framework for documenting and naming > > specific uses of INFO (called INFO packages), for=20 > registering those > > package names with IANA, and for negotiating the support=20 > for various > > INFO packages between applications using SIP. > >=20 > > In the thread so far there have also been suggestions that cover: > >=20 > > - support to mediactrl for their discussion on requirements > > - something for hitchhiker's guide to point to: > > - something that answers all the questions that recur on=20 > this list on=20 > > INFO usage > > - "I've been getting a lot of offline questions asking for=20 > the "right"=20 > > way to carry information related to the session-usage (often=20 > > information that's being tunneled around from companion or=20 > gatewayed=20 > > protocols)." > > - INVITE dialog usage only, or already covered by RFC 2976 > > - It would be OK with me if we ALSO had this type of=20 > guidance ("don't=20 > > look HERE, look over THERE") available ("stated strongly=20 > enough in an=20 > > easy to stumble across place"), but if coming up with that guidance=20 > > takes more than about a week, I don't see a lot of reason=20 > to hold up=20 > > on "don't go there" > > while we explore alternatives. > > - INFO and DTMF > > - XML payloads > > - But people really need is guidance on when to use INFO,=20 > when to use=20 > > events, and when to use something entirely different. > > - identification of purpose of info (Content-Type? - impacted by > > multipart/mixed) > > - any framework for control of usages (IANA registration? - RFC > > 3427 update) > >=20 > > Would anybody out there like to have a go at drafting an=20 > abstract for=20 > > a potential WG deliverable (and also identifying level - Info, BCP,=20 > > standards track) and submitting it to the list for discussion.=20 > > Remember an abstract needs to: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ------- > > Every RFC must have an Abstract section following the=20 > Copyright notice. > > An Abstract will typically be 5-10 lines. An Abstract of=20 > more than 20=20 > > lines is generally not acceptable. > >=20 > > The Abstract section should provide a concise and comprehensive=20 > > overview of the purpose and contents of the entire=20 > document, to give a=20 > > technically knowledgeable reader a general overview of the=20 > function of=20 > > the document. In addition to its function in the RFC itself, the=20 > > Abstract section text will appear in publication=20 > announcements and in=20 > > the online index of RFCs. > >=20 > > Composing a useful Abstract generally requires thought and care.=20 > > Usually an Abstract should begin with a phrase like "This=20 > memo ..." or=20 > > "This document ...". A satisfactory abstract can often be=20 > constructed=20 > > in part from material within the Introduction section, but a good=20 > > abstract will be shorter, less detailed, and perhaps=20 > broader in scope=20 > > than the Introduction. Simply copying and pasting the first few=20 > > paragraphs of the Introduction is tempting, but it may result in an=20 > > Abstract that is both incomplete and redundant. Note also that an=20 > > Abstract is not a substitute for an Introduction; the RFC should be=20 > > self-contained as if there were no Abstract section. > >=20 > > An Abstract should be complete in itself; it should not contain=20 > > citations unless they are completely defined within the Abstract. > > Abbreviations appearing in the Abstract should generally be=20 > expanded=20 > > in parentheses. There is a small set of reasonable=20 > exceptions to this=20 > > rule (see guidelines on abbreviations, above.) > >=20 > ---------------------------------------------------------------------- > > -- > > ------ > >=20 > > And as such should give a clear idea of whether there is=20 > anything we=20 > > should charter here or not. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KPM-00085W-HG; Mon, 18 Jun 2007 12:48:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KPK-00083Z-Mm for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:48:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KPJ-00083B-RK for sip@ietf.org; Mon, 18 Jun 2007 12:48:50 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KPJ-0004b0-66 for sip@ietf.org; Mon, 18 Jun 2007 12:48:49 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5IGmkn2002966; Mon, 18 Jun 2007 09:48:46 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5IGmSIf013771; Mon, 18 Jun 2007 09:48:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Sip] MIME: Nested bodies with option-tag? Date: Mon, 18 Jun 2007 09:48:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] MIME: Nested bodies with option-tag? Thread-Index: AcexuwQ+V1wUDT+JTCOs9/aTbdnbvAADYLqt From: "Eric Burger" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Gateway pass = SIP process Work for you now? -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Paul Kyzivat To: Eric Burger CC: Dale.Worley@comcast.net ; sip@ietf.org Sent: Mon Jun 18 08:11:42 2007 Subject: Re: [Sip] MIME: Nested bodies with option-tag? Eric, I don't understand how to apply this to sip. 3459 defines the criterion for REQUIRED as: If the content gateway cannot pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action. That makes sense for a mail gateway. (I don't know if it makes sense for a mail user agent.) But attempting to apply it to sip still leaves a lot of questions. In particular, I can see that in a mail message the multipart bodies themselves are actually rendered in the sense that they are shown as nested containers. In sip, in general that won't be the case - much of the content won't be "rendered", though it may be "processed" in some sense. Unless we define what we mean by "processing" then I think we haven't finished. Consider a few cases: 1. content-type SDP, content-disposition session;handling=required We know what that means, if in a message where an offer or answer is allowed, or a preview of an offer or answer, or in an OPTIONS response. We don't have a meaning for this in other contexts, such as SUBSCRIBE, NOTIFY, MESSAGE or their responses. If you were to receive the body in one of those, what should be done? Should that be a 415 response? 2. content-type text/plain, content-disposition render;handling=required We know what this means in MESSAGE. What should be done in other requests, or in responses? 3. c-t multipart/mixed, c-d ???;handling=required c-t SDP, c-d session;handling=required c-t application/ISUP, c-d signal;handling=optional I think this should be legal all the same places where (1) is legal. But a recipient that doesn't understand multipart/mixed will return a 415. I don't know what the content-disposition should be for the multipart. I guess for mail the default of render works, because it can really be rendered. That doesn't make sense for sip in this case. I have never seen an example using a multipart/mixed that included a content-disposition for it. AFAIK the default should be "render;handling=required". But for sip I don't know what it means to "render" a multipart. 4. c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is a little silly, but seems legal. If you can handle (3) then you should be able to handle this. Somebody that doesn't handle the multipart would return 415. 5. c-t multipart/mixed; c-d ???;handling=required c-t multipart/mixed; c-d ???;handling=required c-t SDP, c-d session;handling=required This is even sillier. But it raises more issues. If you handle (4), must you also handle this? If it is acceptable to handle (4) and not handle this, then what response should there be? AFAIK these are questions about the application of MIME to sip, that don't seem to have been handled by the mail work because the issues just didn't come up there. Thanks, Paul Eric Burger wrote: > Correct. That is the mechanism specified by RFC 3459. > > > On 6/3/07 6:47 PM, "Dale.Worley@comcast.net" > wrote: > >> From: "DRAGE, Keith \(Keith\)" >> >> Well, at the moment, what I am trying to do is get some understanding of >> what we should scope as valid SIP work. >> >> I've been busy, so I may be behind in the discussion, but it's not >> clear to me that there is anything that needs to be done specifically >> for SIP. I may well be wrong, but my impression is that MIME already >> has the features and specifications neede so that a receiver can >> decide whether it has adequately "understood" the document when it >> only understands some components. These mechanisms are all inherited >> by SIP and I would expect be a sufficient set of rules. >> >> E.g., a UAC that sends a request with a multipart body must expect >> that some UASs will respond with 415, and have some strategy in place >> for dealing with that situation. Similarly, a UAC that sends a nested >> multipart body must expect that some UASs will be unable to process >> the nested multipart, and will either ignore it or reject the request >> (as specified), and the UAC must be prepared to deal with that >> situation. >> >> Is there a reason we need to define new, narrower subsets of allowed >> behaviors and define a SIP mechanism to negotiate these? >> >> Dale >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 12:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KSO-0000kQ-W0; Mon, 18 Jun 2007 12:52:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KSN-0000jt-Gj for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KSM-0000jl-Nn for sip@ietf.org; Mon, 18 Jun 2007 12:51:59 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KSL-0005FA-Gh for sip@ietf.org; Mon, 18 Jun 2007 12:51:58 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5IGprH14573; Mon, 18 Jun 2007 16:51:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Mon, 18 Jun 2007 11:51:39 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> In-Reply-To: <46769AD7.8010606@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Acext4mG9N6QwbMOSVe4RxL6lIUMrQAEVL3Q References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> From: "Francois Audet" To: "Vijay K. Gurbani" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > Right; agree. Forking is problematic. One way is to force=20 > the issue with rfc3841's Request-Disposition header. But=20 > that header elicits a normative strength of SHOULD in the=20 > proxies, thereby lending it an advisory mode only. Another=20 > way is to discourage forking for CONNECT in the draft, but=20 > allow for it to occur and simply accept the first 200 OK,=20 > closing the connection on subsequent ones. Clearly something=20 > that needs to be worked out in the draft going forward. Maybe we can just do the 3XX with multiple contacts? (i.e., UAC-based forking)? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 13:17:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KrJ-0005KK-ER; Mon, 18 Jun 2007 13:17:45 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KrH-0005KB-EV for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KrH-0005K2-50 for sip@ietf.org; Mon, 18 Jun 2007 13:17:43 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KrF-0004sq-SF for sip@ietf.org; Mon, 18 Jun 2007 13:17:43 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5IHHZAW022603; Mon, 18 Jun 2007 12:17:35 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5IHHVa08207; Mon, 18 Jun 2007 12:17:31 -0500 (CDT) Message-ID: <4676BE2B.2010109@alcatel-lucent.com> Date: Mon, 18 Jun 2007 12:17:31 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > > >>Right; agree. Forking is problematic. One way is to force >>the issue with rfc3841's Request-Disposition header. But >>that header elicits a normative strength of SHOULD in the >>proxies, thereby lending it an advisory mode only. Another >>way is to discourage forking for CONNECT in the draft, but >>allow for it to occur and simply accept the first 200 OK, >>closing the connection on subsequent ones. Clearly something >>that needs to be worked out in the draft going forward. > > Maybe we can just do the 3XX with multiple contacts? > (i.e., UAC-based forking)? Yes, that is a third option; although, I would be curious to see how many user agents fork (proxies of course need to). Most user agents that I have used happily leave the complexity of forking to their nearest friendly proxy. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 13:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KwU-0006iX-Tr; Mon, 18 Jun 2007 13:23:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KwT-0006iS-Ee for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KwT-0006iK-57 for sip@ietf.org; Mon, 18 Jun 2007 13:23:05 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KwQ-0006LM-Rr for sip@ietf.org; Mon, 18 Jun 2007 13:23:04 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5IHN1aJ009347; Mon, 18 Jun 2007 10:23:01 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5IHMj29017607; Mon, 18 Jun 2007 10:22:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: AW: [Sip] INFO usage (or not) Date: Mon, 18 Jun 2007 10:22:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASb2EAABI8VbQ= From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Because RFC 2976 is wrong, and we are willing to correct our mistakes. Goo= d news is that other than 3204, there are no documented standards track use= s of INFO. There is one informational RFC that talks about its use in the w= ild (for media server control), but if you look at it (RFC 4722) you will s= ee the #1 reason for using info was that in the day, there was no other alt= ernative. Given NO IETF standards use INFO, and we have been explaining why it is a b= ad idea for close to five years now, I do not see the problem with setting = the record straight. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade:= see for what lemonade is. -----Original Message----- From: Jesske, R To: Eric Burger; drage@alcatel-lucent.com ; sip@i= etf.org Sent: Mon Jun 18 02:01:29 2007 Subject: AW: [Sip] INFO usage (or not) Hi, Why should be RFC's that are now 6 Years out in the world be restricted? RFC 2976 clearly states for what INFO can be used. I'm concerned about implementations that works with INFO regarding the rule= s defined within 2976. Many implementations work based on that RFC. Like define a MIME, put it int= o INFO and it works. I thought also that INFO was defined to put in some end to end information = that shall be exchanged by UA's. Why to restrict such a use in such a case? If RFC 2976 will be changed is backward compatibility guaranteed? Best Regards Roland > -----Urspr=C3=BCngliche Nachricht----- > Von: Eric Burger [mailto:eburger@bea.com]=20 > Gesendet: Sonntag, 17. Juni 2007 11:53 > An: Keith Drage; IETF SIP List > Betreff: Re: [Sip] INFO usage (or not) >=20 >=20 > How about this: >=20 > This document describes why the Session Initiation Protocol (SIP) INFO > method, introduced in RFC 2976, has serious issues with any=20 > use outside its > use as a transport mechanism for ISDN User Part (ISUP) call=20 > signaling in > SIP-signaled networks. In the years since the introduction=20 > of the INFO > method, the IETF has published numerous, interoperable=20 > extensions to SIP. > This document explains why there are INFO-based, proprietary=20 > protocols in > the wild; the flaws of using INFO; and prescriptions for how to use > existing, interoperable SIP mechanisms to accomplish most any of these > tasks. >=20 >=20 > My personal preference is for the document to be Standards=20 > Track and be a > Work Group chartered item. The reason is that for this document to be > useful, it MUST update RFC 2976. If it updates RFC 2976,=20 > then newbies get > the pointer when the download RFC 2976, pointing them to this=20 > document, > before they go off, create draft-mumble-foo-over-INFO, and=20 > get flamed on the > list. The essence of the normative content of the document=20 > is, "one MUST > NOT use INFO for anything other than transporting ISUP or=20 > QSIG messages." >=20 > Because the normative content is so thin, I could understand=20 > not saying that > and making the document Informational (or BCP). However, I=20 > really and truly > believe that will significantly reduce the impact the=20 > document will have. >=20 >=20 > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate under what > circumstances > Update to RFC 2976 > - Limiting use of INFO to ISUP transport only > Security Considerations >=20 >=20 >=20 >=20 >=20 > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > wrote: >=20 > > (As WG chair) > >=20 > > We have got a number of threads floating round on INFO usage, and it > > would be nice to identify this into a potential body of=20 > work, and see if > > there is support for it. > >=20 > > We have two previous drafts that never went anywhere,=20 > although contents > > of both carried support in the WG at the time: > >=20 > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >=20 > > The Session Initiation Protocol (SIP) INFO method=20 > defines a means for > > transporting mid-dialog application layer data between=20 > user agents. > > Its initial use was to support the transport of ISUP mid-call > > messages which could not be mapped to any other SIP=20 > request method. > > However, since its initial usage for that purpose, INFO has seen > > widespread abuse as a means for introducing non-standard and > > non-interoperable extensions to SIP. For this reason,=20 > we now believe > > INFO should be considered harmful, and therefore,=20 > deprecated in its > > current form. > >=20 > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >=20 > > The SIP INFO method (RFC 2976) establishes a method by which > > applications may transfer application-specific=20 > information within a > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > describing and documenting an application of INFO, nor does it > > provide a mechanism by which applications may negotiate=20 > such uses. > > This document provides a framework for documenting and naming > > specific uses of INFO (called INFO packages), for=20 > registering those > > package names with IANA, and for negotiating the support=20 > for various > > INFO packages between applications using SIP. > >=20 > > In the thread so far there have also been suggestions that cover: > >=20 > > - support to mediactrl for their discussion on requirements > > - something for hitchhiker's guide to point to: > > - something that answers all the questions that recur on this list > > on INFO usage > > - "I've been getting a lot of offline questions asking for the > > "right" way to carry information related to the session-usage (often > > information that's being tunneled around from companion or gatewayed > > protocols)." > > - INVITE dialog usage only, or already covered by RFC 2976 > > - It would be OK with me if we ALSO had this type of guidance > > ("don't look HERE, look over THERE") available ("stated=20 > strongly enough > > in an easy to stumble across place"), but if coming up with that > > guidance takes more than about a week, I don't see a lot of=20 > reason to > > hold up on "don't go there" > > while we explore alternatives. > > - INFO and DTMF > > - XML payloads > > - But people really need is guidance on when to use INFO, when to > > use events, and when to use something entirely different. > > - identification of purpose of info (Content-Type? - impacted by > > multipart/mixed) > > - any framework for control of usages (IANA registration? - RFC > > 3427 update) > >=20 > > Would anybody out there like to have a go at drafting an=20 > abstract for a > > potential WG deliverable (and also identifying level - Info, BCP, > > standards track) and submitting it to the list for=20 > discussion. Remember > > an abstract needs to: > >=20 > >=20 > -------------------------------------------------------------- > ---------- > > ------- > > Every RFC must have an Abstract section following the=20 > Copyright notice. > > An Abstract will typically be 5-10 lines. An Abstract of=20 > more than 20 > > lines is generally not acceptable. > >=20 > > The Abstract section should provide a concise and=20 > comprehensive overview > > of the purpose and contents of the entire document, to give a > > technically knowledgeable reader a general overview of the=20 > function of > > the document. In addition to its function in the RFC itself, the > > Abstract section text will appear in publication=20 > announcements and in > > the online index of RFCs. > >=20 > > Composing a useful Abstract generally requires thought and=20 > care. Usually > > an Abstract should begin with a phrase like "This memo ..." or "This > > document ...". A satisfactory abstract can often be=20 > constructed in part > > from material within the Introduction section, but a good=20 > abstract will > > be shorter, less detailed, and perhaps broader in scope than the > > Introduction. Simply copying and pasting the first few=20 > paragraphs of the > > Introduction is tempting, but it may result in an Abstract=20 > that is both > > incomplete and redundant. Note also that an Abstract is not=20 > a substitute > > for an Introduction; the RFC should be self-contained as if=20 > there were > > no Abstract section. > >=20 > > An Abstract should be complete in itself; it should not contain > > citations unless they are completely defined within the Abstract. > > Abbreviations appearing in the Abstract should generally be=20 > expanded in > > parentheses. There is a small set of reasonable exceptions=20 > to this rule > > (see guidelines on abbreviations, above.) > >=20 > -------------------------------------------------------------- > ---------- > > ------ > >=20 > > And as such should give a clear idea of whether there is anything we > > should charter here or not. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 13:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KxY-0007eL-Rt; Mon, 18 Jun 2007 13:24:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0KxV-0007eC-KE for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0KxV-0007e4-9O for sip@ietf.org; Mon, 18 Jun 2007 13:24:09 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0KxU-0006Xx-1j for sip@ietf.org; Mon, 18 Jun 2007 13:24:09 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Jun 2007 13:24:08 -0400 X-IronPort-AV: i="4.16,435,1175486400"; d="scan'208"; a="123919893:sNHT49370110" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5IHO7kp021264; Mon, 18 Jun 2007 13:24:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5IHNwBi007258; Mon, 18 Jun 2007 17:24:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:23:58 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:23:58 -0400 Message-ID: <4676BFAC.3010104@cisco.com> Date: Mon, 18 Jun 2007 13:23:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> In-Reply-To: <4676BE2B.2010109@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 17:23:58.0534 (UTC) FILETIME=[748FC660:01C7B1CD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1019; t=1182187447; x=1183051447; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-gurbani-sip-sipsec-01 |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=YBtMKBG+/WGuYNDIPURntDI2RmSgDIqbpVWUb8sA7dQ=; b=bs5J5i8RKwG8WV5WCKQxSaZmpquZYyo/Xcw9REhRNi/oqwKP0PzwXIlX7KMSiSug1uJ/mpHl eQn5+tdoZ8JmkXHMBf6280XvI1Aexx5ekWmGSaikNwnxQGRzlquMfdCO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: IETF SIP List , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay K. Gurbani wrote: > Francois Audet wrote: >> >> >>> Right; agree. Forking is problematic. One way is to force the issue >>> with rfc3841's Request-Disposition header. But that header elicits a >>> normative strength of SHOULD in the proxies, thereby lending it an >>> advisory mode only. Another way is to discourage forking for CONNECT >>> in the draft, but allow for it to occur and simply accept the first >>> 200 OK, closing the connection on subsequent ones. Clearly something >>> that needs to be worked out in the draft going forward. >> >> Maybe we can just do the 3XX with multiple contacts? >> (i.e., UAC-based forking)? > > Yes, that is a third option; although, I would be curious to > see how many user agents fork (proxies of course need to). > Most user agents that I have used happily leave the complexity > of forking to their nearest friendly proxy. True. But how many UAs support sipsec? :-) This could just be part of implementing sipsec. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 13:27:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L0N-0005lx-H2; Mon, 18 Jun 2007 13:27:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0L0M-0005ls-L8 for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L0M-0005lk-BV for sip@ietf.org; Mon, 18 Jun 2007 13:27:06 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0L0L-0007IV-HE for sip@ietf.org; Mon, 18 Jun 2007 13:27:06 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5IHR16S013513; Mon, 18 Jun 2007 10:27:01 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5IHQiIA021337; Mon, 18 Jun 2007 10:26:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] INFO usage (or not) Date: Mon, 18 Jun 2007 10:26:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7gABK58qQ= From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I agree: in a limited deployment scenario, like an application server conne= cted to a media server using a yellow cable as a proxy and an application b= ought from a single systems integrator, there is no interoperability proble= m. However, the info incompatibility problem is real - I have experienced i= t in the wild. You are correct in asserting that one can make INFO work - we were doing it= in 2001. However, working in the Internet is a different case altoghether= . -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade:= see for what lemonade is. -----Original Message----- From: Christer Holmberg (JO/LMF) To: Eric Burger; Keith Drage ; IETF SIP List Sent: Mon Jun 18 02:19:55 2007 Subject: RE: [Sip] INFO usage (or not) Hi, I am very concerned some some people use the word "newbies", and make it so= und that people using INFO are beginners which have no clue about SIP. Also, I have never heard about interoperability problems with INFO. One rea= son people are using INFO for certain things IS in order to interop with ot= her implementations. I am also confused that people seem to think that INFOs will start flying a= round for no reason, without the sender having any clue about whether the r= eceiver will understand them or not. As we have discussed, there ARE mechan= isms in SIP to negotiate what content types etc entities support. Yes, MAYB= E we need to extend that (e.g. being able to indicate which methods can be = used to carry a specific content type), if what we have is not enough. But,= to me that is not the same thing has having "tons of problem". Having said that, if there are issues with INFO, I have nothing against dis= cussing them. But, if you are going to talk about alternative solutions, yo= u also need to look at possible issues with those (having to set up multipl= e dialogs just in order to send some DTMFs associated with another dialog e= tc).=20 We can sit in our meeting rooms and wri= te whatever you-must-to-this-and-you-must-not-do-that documents, but if we = don't care about the feedback we get from the real world OUTSIDE the meetin= g room it won't help much. In the long run it will cause more harm than goo= d. Regards, Christer =20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: 17. kes=C3=A4kuuta 2007 12:53 > To: Keith Drage; IETF SIP List > Subject: Re: [Sip] INFO usage (or not) >=20 > How about this: >=20 > This document describes why the Session Initiation Protocol=20 > (SIP) INFO method, introduced in RFC 2976, has serious issues=20 > with any use outside its use as a transport mechanism for=20 > ISDN User Part (ISUP) call signaling in SIP-signaled=20 > networks. In the years since the introduction of the INFO=20 > method, the IETF has published numerous, interoperable=20 > extensions to SIP. > This document explains why there are INFO-based, proprietary=20 > protocols in the wild; the flaws of using INFO; and=20 > prescriptions for how to use existing, interoperable SIP=20 > mechanisms to accomplish most any of these tasks. >=20 >=20 > My personal preference is for the document to be Standards=20 > Track and be a Work Group chartered item. The reason is that=20 > for this document to be useful, it MUST update RFC 2976. If=20 > it updates RFC 2976, then newbies get the pointer when the=20 > download RFC 2976, pointing them to this document, before=20 > they go off, create draft-mumble-foo-over-INFO, and get=20 > flamed on the list. The essence of the normative content of=20 > the document is, "one MUST NOT use INFO for anything other=20 > than transporting ISUP or QSIG messages." >=20 > Because the normative content is so thin, I could understand=20 > not saying that and making the document Informational (or=20 > BCP). However, I really and truly believe that will=20 > significantly reduce the impact the document will have. >=20 >=20 > Outline: > Introduction > - Requirements for UA-to-UA signaling > - The INFO method > - The INFO method for ISUP signaling > Issues with INFO > - No or incomplete negotiation > - No real identification of payload purpose on receipt=20 > Alternatives to INFO > - State Updates: SUBSCRIBE / NOTIFY > - DTMF Transport: KPML (an example of state updates) > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > - Prescriptions for deciding which method is appropriate=20 > under what circumstances Update to RFC 2976 > - Limiting use of INFO to ISUP transport only Security Considerations >=20 >=20 >=20 >=20 >=20 > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > wrote: >=20 > > (As WG chair) > >=20 > > We have got a number of threads floating round on INFO=20 > usage, and it=20 > > would be nice to identify this into a potential body of=20 > work, and see=20 > > if there is support for it. > >=20 > > We have two previous drafts that never went anywhere, although=20 > > contents of both carried support in the WG at the time: > >=20 > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >=20 > > The Session Initiation Protocol (SIP) INFO method=20 > defines a means for > > transporting mid-dialog application layer data between=20 > user agents. > > Its initial use was to support the transport of ISUP mid-call > > messages which could not be mapped to any other SIP=20 > request method. > > However, since its initial usage for that purpose, INFO has seen > > widespread abuse as a means for introducing non-standard and > > non-interoperable extensions to SIP. For this reason,=20 > we now believe > > INFO should be considered harmful, and therefore,=20 > deprecated in its > > current form. > >=20 > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >=20 > > The SIP INFO method (RFC 2976) establishes a method by which > > applications may transfer application-specific=20 > information within a > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > describing and documenting an application of INFO, nor does it > > provide a mechanism by which applications may negotiate=20 > such uses. > > This document provides a framework for documenting and naming > > specific uses of INFO (called INFO packages), for=20 > registering those > > package names with IANA, and for negotiating the support=20 > for various > > INFO packages between applications using SIP. > >=20 > > In the thread so far there have also been suggestions that cover: > >=20 > > - support to mediactrl for their discussion on requirements > > - something for hitchhiker's guide to point to: > > - something that answers all the questions that recur on=20 > this list on=20 > > INFO usage > > - "I've been getting a lot of offline questions asking for=20 > the "right"=20 > > way to carry information related to the session-usage (often=20 > > information that's being tunneled around from companion or=20 > gatewayed=20 > > protocols)." > > - INVITE dialog usage only, or already covered by RFC 2976 > > - It would be OK with me if we ALSO had this type of=20 > guidance ("don't=20 > > look HERE, look over THERE") available ("stated strongly=20 > enough in an=20 > > easy to stumble across place"), but if coming up with that guidance=20 > > takes more than about a week, I don't see a lot of reason=20 > to hold up=20 > > on "don't go there" > > while we explore alternatives. > > - INFO and DTMF > > - XML payloads > > - But people really need is guidance on when to use INFO,=20 > when to use=20 > > events, and when to use something entirely different. > > - identification of purpose of info (Content-Type? - impacted by > > multipart/mixed) > > - any framework for control of usages (IANA registration? - RFC > > 3427 update) > >=20 > > Would anybody out there like to have a go at drafting an=20 > abstract for=20 > > a potential WG deliverable (and also identifying level - Info, BCP,=20 > > standards track) and submitting it to the list for discussion.=20 > > Remember an abstract needs to: > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > > ------- > > Every RFC must have an Abstract section following the=20 > Copyright notice. > > An Abstract will typically be 5-10 lines. An Abstract of=20 > more than 20=20 > > lines is generally not acceptable. > >=20 > > The Abstract section should provide a concise and comprehensive=20 > > overview of the purpose and contents of the entire=20 > document, to give a=20 > > technically knowledgeable reader a general overview of the=20 > function of=20 > > the document. In addition to its function in the RFC itself, the=20 > > Abstract section text will appear in publication=20 > announcements and in=20 > > the online index of RFCs. > >=20 > > Composing a useful Abstract generally requires thought and care.=20 > > Usually an Abstract should begin with a phrase like "This=20 > memo ..." or=20 > > "This document ...". A satisfactory abstract can often be=20 > constructed=20 > > in part from material within the Introduction section, but a good=20 > > abstract will be shorter, less detailed, and perhaps=20 > broader in scope=20 > > than the Introduction. Simply copying and pasting the first few=20 > > paragraphs of the Introduction is tempting, but it may result in an=20 > > Abstract that is both incomplete and redundant. Note also that an=20 > > Abstract is not a substitute for an Introduction; the RFC should be=20 > > self-contained as if there were no Abstract section. > >=20 > > An Abstract should be complete in itself; it should not contain=20 > > citations unless they are completely defined within the Abstract. > > Abbreviations appearing in the Abstract should generally be=20 > expanded=20 > > in parentheses. There is a small set of reasonable=20 > exceptions to this=20 > > rule (see guidelines on abbreviations, above.) > >=20 > ---------------------------------------------------------------------- > > -- > > ------ > >=20 > > And as such should give a clear idea of whether there is=20 > anything we=20 > > should charter here or not. > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 13:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L1t-00073F-3H; Mon, 18 Jun 2007 13:28:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0L1r-000739-9E for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:28:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L1q-000731-W1 for sip@ietf.org; Mon, 18 Jun 2007 13:28:38 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0L1p-0007g2-Pk for sip@ietf.org; Mon, 18 Jun 2007 13:28:38 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5IHSUb16085; Mon, 18 Jun 2007 17:28:30 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Mon, 18 Jun 2007 12:28:29 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10E7A951@zrc2hxm0.corp.nortel.com> In-Reply-To: <4676BFAC.3010104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AcexzXwc5bzj9bMBTGiWIY/B9txNJAAAImog References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > > Yes, that is a third option; although, I would be curious=20 > to see how=20 > > many user agents fork (proxies of course need to). > > Most user agents that I have used happily leave the complexity of=20 > > forking to their nearest friendly proxy. >=20 > True. But how many UAs support sipsec? :-) >=20 > This could just be part of implementing sipsec. Yes, that is exactly what I was thinking.=20 Let's make it clean. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 16:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NP1-0006eT-EZ; Mon, 18 Jun 2007 16:00:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0NP0-0006eJ-4J for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NOz-0006e6-Pn for sip@ietf.org; Mon, 18 Jun 2007 16:00:41 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NOy-00009K-Fm for sip@ietf.org; Mon, 18 Jun 2007 16:00:41 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJU00I0FKWS4J@siemenscomms.co.uk> for sip@ietf.org; Mon, 18 Jun 2007 21:00:28 +0100 (BST) Date: Mon, 18 Jun 2007 21:00:38 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 In-reply-to: <4672BADD.3090008@alcatel-lucent.com> To: "Vijay K. Gurbani" , Jeroen van Bemmel Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E8DC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AcevaEv11aHPunC3SpesUUMTUmChGgCei0cw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672BADD.3090008@alcatel-lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, > > Also, I would suggest to make CONNECT a well formed SIP request > > (possibly with dummy values). > > The current draft does not limit the headers that can appear > in a CONNECT request. From intermediary transaction idenitification > point of view, only a Via is needed. Dialog usage that requires > To, From and Call-ID is an endpoint function, and in this case, > the endpoint has other means to establish that dialog (i.e., set > up the TLS tunnel and then send a dialog-establishing request over > it.) > > > That would allow current proxies to participate in phase 1 > of CONNECT > > without change (although they might Record-Route since CONNECT would > > be an unknown method - would need to strip such proxies from the > > discovered Route, e.g. by mandating a special tag to use for R-R for > > proxies that know what they're doing, removing all other entries) RFC 3261 section 8.1.1 states: "A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions." Even if all these header fields are not strictly needed by entities that support sipsec, I think we should continue to mandate them, even if they contain dummy values. Otherwise it might have unnecessary impact on SIP stacks or might lead to unexpected responses (e.g. 400). John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 16:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NYq-0003bg-Oz; Mon, 18 Jun 2007 16:10:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0NYo-0003aB-BE for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0NYn-0003Zk-PT for sip@ietf.org; Mon, 18 Jun 2007 16:10:49 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0NYi-0004ey-Qk for sip@ietf.org; Mon, 18 Jun 2007 16:10:49 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 540EC20496; Mon, 18 Jun 2007 22:10:44 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-1e-4676e6c4e32c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 34BB42004E; Mon, 18 Jun 2007 22:10:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 22:10:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Mon, 18 Jun 2007 22:10:42 +0200 Message-ID: <7374777208BDC7449D5620EF942325670576D590@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7gABK58qQABYFnAA== References: From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , X-OriginalArrivalTime: 18 Jun 2007 20:10:43.0905 (UTC) FILETIME=[C03A3B10:01C7B1E4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I agree: in a limited deployment scenario, like an=20 >application server connected to a media server using a yellow=20 >cable as a proxy and an application bought from a single=20 >systems integrator, there is no interoperability problem.=20 >However, the info incompatibility problem is real - I have=20 >experienced it in the wild. So, why don't you explain what problems you have seen? Because, I have seen implementations - from different vendors - working = fine togheter. Of course, maybe there are also implementations which do NOT interop = widely, but they probably have been implemented without any use of the = negotiation mechanisms etc that we have in SIP, with a very limited = deployment scope in mind. There is not much we can do about that, but = those kind of scenarios are not what I have been talking about. =20 >You are correct in asserting that one can make INFO work - we=20 >were doing it in 2001. However, working in the Internet is a=20 >different case altoghether. What do you mean by "Internet"? Regards, Christer > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF) > To: Eric Burger; Keith Drage ; IETF=20 > SIP List > Sent: Mon Jun 18 02:19:55 2007 > Subject: RE: [Sip] INFO usage (or not) >=20 >=20 > Hi, >=20 > I am very concerned some some people use the word "newbies",=20 > and make it sound that people using INFO are beginners which=20 > have no clue about SIP. >=20 > Also, I have never heard about interoperability problems with=20 > INFO. One reason people are using INFO for certain things IS=20 > in order to interop with other implementations. >=20 > I am also confused that people seem to think that INFOs will=20 > start flying around for no reason, without the sender having=20 > any clue about whether the receiver will understand them or=20 > not. As we have discussed, there ARE mechanisms in SIP to=20 > negotiate what content types etc entities support. Yes, MAYBE=20 > we need to extend that (e.g. being able to indicate which=20 > methods can be used to carry a specific content type), if=20 > what we have is not enough. But, to me that is not the same=20 > thing has having "tons of problem". >=20 > Having said that, if there are issues with INFO, I have=20 > nothing against discussing them. But, if you are going to=20 > talk about alternative solutions, you also need to look at=20 > possible issues with those (having to set up multiple dialogs=20 > just in order to send some DTMFs associated with another dialog etc).=20 >=20 > We can sit in our meeting=20 > rooms and write whatever=20 > you-must-to-this-and-you-must-not-do-that documents, but if=20 > we don't care about the feedback we get from the real world=20 > OUTSIDE the meeting room it won't help much. In the long run=20 > it will cause more harm than good. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 17. kes=E4kuuta 2007 12:53 > > To: Keith Drage; IETF SIP List > > Subject: Re: [Sip] INFO usage (or not) > >=20 > > How about this: > >=20 > > This document describes why the Session Initiation Protocol > > (SIP) INFO method, introduced in RFC 2976, has serious=20 > issues with any=20 > > use outside its use as a transport mechanism for ISDN User=20 > Part (ISUP)=20 > > call signaling in SIP-signaled networks. In the years since the=20 > > introduction of the INFO method, the IETF has published numerous,=20 > > interoperable extensions to SIP. > > This document explains why there are INFO-based,=20 > proprietary protocols=20 > > in the wild; the flaws of using INFO; and prescriptions for=20 > how to use=20 > > existing, interoperable SIP mechanisms to accomplish most=20 > any of these=20 > > tasks. > >=20 > >=20 > > My personal preference is for the document to be Standards=20 > Track and=20 > > be a Work Group chartered item. The reason is that for=20 > this document=20 > > to be useful, it MUST update RFC 2976. If it updates RFC=20 > 2976, then=20 > > newbies get the pointer when the download RFC 2976,=20 > pointing them to=20 > > this document, before they go off, create=20 > draft-mumble-foo-over-INFO,=20 > > and get flamed on the list. The essence of the normative=20 > content of=20 > > the document is, "one MUST NOT use INFO for anything other than=20 > > transporting ISUP or QSIG messages." > >=20 > > Because the normative content is so thin, I could understand not=20 > > saying that and making the document Informational (or BCP).=20 > However,=20 > > I really and truly believe that will significantly reduce=20 > the impact=20 > > the document will have. > >=20 > >=20 > > Outline: > > Introduction > > - Requirements for UA-to-UA signaling > > - The INFO method > > - The INFO method for ISUP signaling > > Issues with INFO > > - No or incomplete negotiation > > - No real identification of payload purpose on receipt=20 > Alternatives to=20 > > INFO > > - State Updates: SUBSCRIBE / NOTIFY > > - DTMF Transport: KPML (an example of state updates) > > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > > - Prescriptions for deciding which method is appropriate under what=20 > > circumstances Update to RFC 2976 > > - Limiting use of INFO to ISUP transport only Security=20 > Considerations > >=20 > >=20 > >=20 > >=20 > >=20 > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > > wrote: > >=20 > > > (As WG chair) > > >=20 > > > We have got a number of threads floating round on INFO > > usage, and it > > > would be nice to identify this into a potential body of > > work, and see > > > if there is support for it. > > >=20 > > > We have two previous drafts that never went anywhere, although=20 > > > contents of both carried support in the WG at the time: > > >=20 > > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > >=20 > > > The Session Initiation Protocol (SIP) INFO method > > defines a means for > > > transporting mid-dialog application layer data between > > user agents. > > > Its initial use was to support the transport of ISUP mid-call > > > messages which could not be mapped to any other SIP > > request method. > > > However, since its initial usage for that purpose,=20 > INFO has seen > > > widespread abuse as a means for introducing non-standard and > > > non-interoperable extensions to SIP. For this reason, > > we now believe > > > INFO should be considered harmful, and therefore, > > deprecated in its > > > current form. > > >=20 > > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > >=20 > > > The SIP INFO method (RFC 2976) establishes a method by which > > > applications may transfer application-specific > > information within a > > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > > describing and documenting an application of INFO, nor does it > > > provide a mechanism by which applications may negotiate > > such uses. > > > This document provides a framework for documenting and naming > > > specific uses of INFO (called INFO packages), for > > registering those > > > package names with IANA, and for negotiating the support > > for various > > > INFO packages between applications using SIP. > > >=20 > > > In the thread so far there have also been suggestions that cover: > > >=20 > > > - support to mediactrl for their discussion on requirements > > > - something for hitchhiker's guide to point to: > > > - something that answers all the questions that recur on > > this list on > > > INFO usage > > > - "I've been getting a lot of offline questions asking for > > the "right"=20 > > > way to carry information related to the session-usage (often=20 > > > information that's being tunneled around from companion or > > gatewayed > > > protocols)." > > > - INVITE dialog usage only, or already covered by RFC 2976 > > > - It would be OK with me if we ALSO had this type of > > guidance ("don't > > > look HERE, look over THERE") available ("stated strongly > > enough in an > > > easy to stumble across place"), but if coming up with=20 > that guidance=20 > > > takes more than about a week, I don't see a lot of reason > > to hold up > > > on "don't go there" > > > while we explore alternatives. > > > - INFO and DTMF > > > - XML payloads > > > - But people really need is guidance on when to use INFO, > > when to use > > > events, and when to use something entirely different. > > > - identification of purpose of info (Content-Type? - impacted by > > > multipart/mixed) > > > - any framework for control of usages (IANA registration? - RFC > > > 3427 update) > > >=20 > > > Would anybody out there like to have a go at drafting an > > abstract for > > > a potential WG deliverable (and also identifying level -=20 > Info, BCP,=20 > > > standards track) and submitting it to the list for discussion. > > > Remember an abstract needs to: > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > > ------- > > > Every RFC must have an Abstract section following the > > Copyright notice. > > > An Abstract will typically be 5-10 lines. An Abstract of > > more than 20 > > > lines is generally not acceptable. > > >=20 > > > The Abstract section should provide a concise and comprehensive=20 > > > overview of the purpose and contents of the entire > > document, to give a > > > technically knowledgeable reader a general overview of the > > function of > > > the document. In addition to its function in the RFC itself, the=20 > > > Abstract section text will appear in publication > > announcements and in > > > the online index of RFCs. > > >=20 > > > Composing a useful Abstract generally requires thought and care.=20 > > > Usually an Abstract should begin with a phrase like "This > > memo ..." or > > > "This document ...". A satisfactory abstract can often be > > constructed > > > in part from material within the Introduction section, but a good=20 > > > abstract will be shorter, less detailed, and perhaps > > broader in scope > > > than the Introduction. Simply copying and pasting the first few=20 > > > paragraphs of the Introduction is tempting, but it may=20 > result in an=20 > > > Abstract that is both incomplete and redundant. Note also that an=20 > > > Abstract is not a substitute for an Introduction; the RFC=20 > should be=20 > > > self-contained as if there were no Abstract section. > > >=20 > > > An Abstract should be complete in itself; it should not contain=20 > > > citations unless they are completely defined within the Abstract. > > > Abbreviations appearing in the Abstract should generally be > > expanded > > > in parentheses. There is a small set of reasonable > > exceptions to this > > > rule (see guidelines on abbreviations, above.) > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > > ------ > > >=20 > > > And as such should give a clear idea of whether there is > > anything we > > > should charter here or not. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > > Notice: This email message, together with any attachments, may=20 > > contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > > affiliated entities, that may be confidential, proprietary, =20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 16:24:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Nlv-0006Qo-Vi; Mon, 18 Jun 2007 16:24:23 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Nlt-0006QL-Pj for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Nlt-0006QA-Fr for sip@ietf.org; Mon, 18 Jun 2007 16:24:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Nls-0003S7-29 for sip@ietf.org; Mon, 18 Jun 2007 16:24:21 -0400 Received: (qmail invoked by alias); 18 Jun 2007 20:24:19 -0000 Received: from p549853D3.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.83.211] by mail.gmx.net (mp047) with SMTP; 18 Jun 2007 22:24:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+NkLQNrgSNiHvb2pHJxntDXgA+gINACFdNRKgFRm dgWqEis9yEOG8p Message-ID: <4676E9F3.4030103@gmx.net> Date: Mon, 18 Jun 2007 22:24:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Andreas.Pashalidis@netlab.nec.de Subject: [Sip] SIP SAML Review by Andreas Pashalidis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Here is a review by Andreas Pashalidis: ---------------------- Here are a few small comments: "trait-based" authentication sounds a bit unconventional. Cannot you just talk about "attribute-based" authorization? That would be better aligned with SAML terminology. >From the description in section 5 and figure 1, it is not always clear if you talk about an "authentication assertion" or an "attribute assertion" - Figure 2, step 5: is it possible to have multiple attribute statements in the response? (for example, if possession of multiple attributes is required?) Section 6.1.4.1.4: what does it mean if there is no attribute statement? is it an authentication assertion then? if yes, what would be the authentication context? Section 9.2: it would be nice to have some exaplanation there, without having to refer to a different spec/document. Thats all for now. Gruss, Andreas -- all primes are odd, except two, and this is the oddest of all! _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 16:27:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Noj-0008DC-5z; Mon, 18 Jun 2007 16:27:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Noh-0008Co-8K for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 16:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Nog-0008Ca-Us for sip@ietf.org; Mon, 18 Jun 2007 16:27:14 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Nof-0006MA-Ka for sip@ietf.org; Mon, 18 Jun 2007 16:27:14 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5IKRDd3009253; Mon, 18 Jun 2007 15:27:13 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5IKRCa16642; Mon, 18 Jun 2007 15:27:12 -0500 (CDT) Message-ID: <4676EAA0.8070504@alcatel-lucent.com> Date: Mon, 18 Jun 2007 15:27:12 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672BADD.3090008@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8DC@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E8DC@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Vijay, [...] > RFC 3261 section 8.1.1 states: > "A valid SIP request formulated by a UAC MUST, at a minimum, contain > the following header fields: To, From, CSeq, Call-ID, Max-Forwards, > and Via; all of these header fields are mandatory in all SIP > requests. [...] > Even if all these header fields are not strictly needed by entities that > support sipsec, I think we should continue to mandate them, even if they > contain dummy values. Otherwise it might have unnecessary impact on SIP > stacks or might lead to unexpected responses (e.g. 400). John: You are absolutely right. Miraculously, the authors of the draft acquired selective amnesia with respect to S8.1.1 of rfc3261 when drafting the contents of the CONNECT request ;-) This will be rectified in subsequent revisions with appropriate view towards privacy. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 18 20:55:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Rzt-0001fr-SJ; Mon, 18 Jun 2007 20:55:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Rzs-0001fm-8q for sip-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 20:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Rzr-0001fe-Vd for sip@ietf.org; Mon, 18 Jun 2007 20:55:03 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Rzp-0004sZ-Lb for sip@ietf.org; Mon, 18 Jun 2007 20:55:03 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5J0suYi027064; Mon, 18 Jun 2007 19:54:56 -0500 (CDT) Received: from [135.244.1.214] (vkg.lra.lucent.com [135.244.1.214]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5J0sta27636; Mon, 18 Jun 2007 19:54:55 -0500 (CDT) Message-ID: <46772959.5010407@alcatel-lucent.com> Date: Mon, 18 Jun 2007 19:54:49 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Paul Kyzivat , Francois Audet Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> In-Reply-To: <4676BFAC.3010104@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > True. But how many UAs support sipsec? :-) Touche! Nothing like reality biting back in the face. ;-) So let's think this through. Francois suggested proxies don't fork and return 3xx, possibly with multiple contacts and let the UAC decide if it wants to fork. This is certainly possible, although having implemented forking and response aggregation in a SIP stack, I know that this is a non-trivial amount of complexity that now every UA would have to implement if it wants to support sipsec. Now, one thing that we have discovered that is sub-optimal about proxies that recurse instead of sending a 3xx to the UA is the potential for upgrading a sip URI to sips and downgrading in reverse. With sipsec, such upgrading or downgrading at proxies does not matter. Eventually, over any transport (sip or sips) chosen by the proxy, certs would be exchanged end-to-end. For this reason, it would be good if we don't force the endpoint to support forking. And finally, forking a non-INVITE request at a proxy should still result in one 2xx, or a best non-2xx being returned to the UAC. So user agents can inherit much of the current transaction-related behavior for CONNECT and augment it with the certificate and tunnel behavior. Thoughts? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 02:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Xaa-00011g-Va; Tue, 19 Jun 2007 02:53:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0XaZ-00011V-1Z for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 02:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0XaV-0000ut-AH for sip@ietf.org; Tue, 19 Jun 2007 02:53:15 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0XaU-0002Xq-17 for sip@ietf.org; Tue, 19 Jun 2007 02:53:15 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJV00E2VF4EPR@siemenscomms.co.uk> for sip@ietf.org; Tue, 19 Jun 2007 07:53:02 +0100 (BST) Date: Tue, 19 Jun 2007 07:53:12 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 In-reply-to: <46772959.5010407@alcatel-lucent.com> To: "Vijay K. Gurbani" , Paul Kyzivat , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceyDIhel7LNZ5MhT6ivddc9myYEEwAMapSw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, > And finally, forking a non-INVITE request at a proxy should > still result in one 2xx, or a best non-2xx being returned to > the UAC. So user agents can inherit much of the current > transaction-related behavior for CONNECT and augment it with > the certificate and tunnel behavior. [JRE] I just don't get how this would work. The UAC receives only one 2xx and as a result initiates one TLS handshake with the UAS concerned. The UAC never gets to hear about any of the other forked-to UASs that might have sent a 2xx, so can never establish a tunnel with those. John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 04:10:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ymy-0005Fn-DB; Tue, 19 Jun 2007 04:10:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Ymw-0005FX-IV for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 04:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ymw-0005FP-2j for sip@ietf.org; Tue, 19 Jun 2007 04:10:10 -0400 Received: from datnt07.tieto.com ([194.110.47.24] helo=tietoe03.tietoenator.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Yms-0002df-IY for sip@ietf.org; Tue, 19 Jun 2007 04:10:10 -0400 X-AuditID: c26e2f18-000000c800001920-88-46778f482f90 Received: from viper.eu.tieto.com ([194.110.47.167]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:09:44 +0300 Received: from sagaris.eu.tieto.com ([131.207.197.143]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:10:04 +0300 Received: from 10.15.1.83 ([10.15.1.83]) by sagaris.eu.tieto.com ([131.207.197.143]) via Exchange Front-End Server email2.tietoenator.com ([192.176.143.12]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jun 2007 08:10:04 +0000 Received: from ww003517.tieto.eu.com by email2.tietoenator.com; 19 Jun 2007 10:10:45 +0200 From: Martin Hynar To: Aki Niemi In-Reply-To: <467262D9.9020606@nokia.com> References: <1181734355.6595.18.camel@ww003517.tieto.eu.com> <467262D9.9020606@nokia.com> Date: Tue, 19 Jun 2007 10:10:45 +0200 Message-Id: <1182240645.5120.22.camel@ww003517.tieto.eu.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) X-OriginalArrivalTime: 19 Jun 2007 08:10:04.0929 (UTC) FILETIME=[3E33D710:01C7B249] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: sip@ietf.org Subject: [Sip] Re: Several notes to entity-tags for SIP Events X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1332499011==" Errors-To: sip-bounces@ietf.org --===============1332499011== Content-Type: multipart/alternative; boundary="=-pmh9hN/ONg1fZ1U6xYkk" --=-pmh9hN/ONg1fZ1U6xYkk Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, ad 1: Now I understand the meaning correctly. ad 4: Here I have on mind subscription to changes in documents created using mechanism described in sip-xcap-config (formerly sipping-config-framework). This way, client might subscribe to changes in multiple documents e.g. under one AUID: Event: ua-profile;profile-type=application;auid="rls-services";Vendor="v";Model="m";Version="v" This way all documents owned by subscriber are subscribed for changes. If changes in multiple documents occur, the server might notify about these changes using one notification and format described in simple-xcap-diff. However, this way the notification carries change in two independent resources. And the problem, if subscriber includes "Supported: subnot-etags" then server shall include SIP-ETag header containing actual entity value of the resource in the notification body. How this notification can carry entity values of multiple documents? ad 2: At the moment I have no better wording in my mind but I will still think about it. br, Martin On Fri, 2007-06-15 at 12:58 +0300, Aki Niemi wrote: > Inline. > > ext Martin Hynar wrote: > > Hello, > > > > I read through the draft sip-subnot-etags-00 and I found several issues > > that needs to be clarified. > > > > 1. typo in introduction > > In sentence "Typically, a SUBSCRIBE request is issued whenever a > > subscription is installed, periodically refreshed or terminated." shall > > be probably "NOTIFY". > > No, it really means SUBSCRIBE, but I think it's a little confusing. Perhaps: > > Typically, a SUBSCRIBE request is issued by the subscriber > whenever it needs a subscription to be installed, periodically > refreshed or terminated. > > > 2. some kind of misleading in text when talking about SIP PUBLISH > > message as an example of entity tags usage. When talking about PUBLISH I > > think, there is slightly different usage scenario. In response to > > initial PUBLISH message, server generates entity tag. Client is mandated > > to use this entity tag if she wants to change state of that particular > > presence source. If this entity tag is not used, PUBLISH message > > installs new presence source and not overwrites the former state. For > > purposes of presence notifications, these publications are then > > composed. This usage is a bit different that supposed for SUBSCRIBE > > messages, The text evokes feeling of something different. > > Yes, the details in PUBLISH are a bit different. Do you have better > wording in mind? > > > 3. What is exactly meant with "Meta-information-check"? What is this > > meta information. > > Entity-tag for one. Added: > > ...meta-information related to a resource, e.g., its current > entity-tag value. > > > 4. Besides RLS subscriptions there is one more problem, the > > subscriptions to changes in documents. So extend the problem also on > > notification about changes in multiple documents. > > Don't understand what you mean by "multiple documents". What use-case do > you have in mind? > > > 5. In my mind, there popped up an idea to move the SIP-Etag into the > > response to SUBSCRIBE message. This way client can be informed about the > > entity tag also without sending the NOTIFY message at all. Have you > > considered this possibility? > > Yes, this was considered, but rejected as there is currently no use for > it in the 2xx. The way the "Suppress-Notify-If-Match" condition works is > that a) the etag is the same and a 204 response is generated and b) the > etag has changed and a NOTIFY is generated, which includes the new etag > in SIP-ETag. > > > 6. What about situation when e.g. presentity has no presence document > > installed and some body subscribes her. The the notifier sends empty > > document, wouldn't be there some special handling? E.g. no entity tag. > > There is nothing specific to subnot-etags in this case. > > The server basically has two choices. Either it generates an etag for > the empty document, and as a publication is received, changes that etag > to a new value; or the server treats the empty document as some sort of > floor value, gives it a constant etag value, in which case a subscriber > that fetched an empty document once, would never get an update in case > it happened to fetch again when there was no active publication. > > Either option is completely an implementation detail. > > Cheers, > Aki +-------------------------------------+ Martin Hynar Software Specialist TietoEnator Czech Software Center Phone: +420 597 459 713 Mobile: +420 724 432 817 E-mail: Martin.Hynar@TietoEnator.com Vystavni 292/13 CZ-709 16 Ostrava www.tietoenator.com Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying 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. --=-pmh9hN/ONg1fZ1U6xYkk Content-Type: text/html; charset=utf-8 Hello,

ad 1: Now I understand the meaning correctly.

ad 4: Here I have on mind subscription to changes in documents created using mechanism described in sip-xcap-config (formerly sipping-config-framework). This way, client might subscribe to changes in multiple documents e.g. under one AUID:

Event: ua-profile;profile-type=application;auid="rls-services";Vendor="v";Model="m";Version="v"

This way all documents owned by subscriber are subscribed for changes. If changes in multiple documents occur, the server might notify about these changes using one notification and format described in simple-xcap-diff. However, this way the notification carries change in two independent resources. And the problem, if subscriber includes "Supported: subnot-etags" then server shall include SIP-ETag header containing actual entity value of the resource in the notification body. How this notification can carry entity values of multiple documents?

ad 2: At the moment I have no better wording in my mind but I will still think about it.

br, Martin


On Fri, 2007-06-15 at 12:58 +0300, Aki Niemi wrote: 
Inline.

ext Martin Hynar wrote:
> Hello,
> 
> I read through the draft sip-subnot-etags-00 and I found several issues 
> that needs to be clarified.
>  
> 1. typo in introduction
> In sentence "Typically, a SUBSCRIBE request is issued whenever a 
> subscription is installed, periodically refreshed or terminated." shall 
> be probably "NOTIFY".

No, it really means SUBSCRIBE, but I think it's a little confusing. Perhaps:

	Typically, a SUBSCRIBE request is issued by the subscriber
         whenever it needs a subscription to be installed, periodically
         refreshed or terminated.

> 2. some kind of misleading in text when talking about SIP PUBLISH 
> message as an example of entity tags usage. When talking about PUBLISH I 
> think, there is slightly different usage scenario. In response to 
> initial PUBLISH message, server generates entity tag. Client is mandated 
> to use this entity tag if she wants to change state of that particular 
> presence source. If this entity tag is not used, PUBLISH message 
> installs new presence source and not overwrites the former state. For 
> purposes of presence notifications, these publications are then 
> composed. This usage is a bit different that supposed for SUBSCRIBE 
> messages, The text evokes feeling of something different.

Yes, the details in PUBLISH are a bit different. Do you have better 
wording in mind?

> 3. What is exactly meant with "Meta-information-check"? What is this 
> meta information.

Entity-tag for one. Added:

	...meta-information related to a resource, e.g., its current
  	entity-tag value.

> 4. Besides RLS subscriptions there is one more problem, the 
> subscriptions to changes in documents. So extend the problem also on 
> notification about changes in multiple documents.

Don't understand what you mean by "multiple documents". What use-case do 
you have in mind?

> 5. In my mind, there popped up an idea to move the SIP-Etag into the 
> response to SUBSCRIBE message. This way client can be informed about the 
> entity tag also without sending the NOTIFY message at all. Have you 
> considered this possibility?

Yes, this was considered, but rejected as there is currently no use for 
it in the 2xx. The way the "Suppress-Notify-If-Match" condition works is 
that a) the etag is the same and a 204 response is generated and b) the 
etag has changed and a NOTIFY is generated, which includes the new etag 
in SIP-ETag.

> 6. What about situation when e.g. presentity has no presence document 
> installed and some body subscribes her. The the notifier sends empty 
> document, wouldn't be there some special handling? E.g. no entity tag.

There is nothing specific to subnot-etags in this case.

The server basically has two choices. Either it generates an etag for 
the empty document, and as a publication is received, changes that etag 
to a new value; or the server treats the empty document as some sort of 
floor value, gives it a constant etag value, in which case a subscriber 
that fetched an empty document once, would never get an update in case 
it happened to fetch again when there was no active publication.

Either option is completely an implementation detail.

Cheers,
Aki
+-------------------------------------+
  Martin Hynar
  Software Specialist

  TietoEnator
  Czech Software Center
  Phone: +420 597 459 713
  Mobile: +420 724 432 817
  E-mail: Martin.Hynar@TietoEnator.com

  Vystavni 292/13
  CZ-709 16 Ostrava

www.tietoenator.com


Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, distribution or copying 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.
--=-pmh9hN/ONg1fZ1U6xYkk-- --===============1332499011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1332499011==-- From sip-bounces@ietf.org Tue Jun 19 04:31:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Z74-0003J6-QT; Tue, 19 Jun 2007 04:30:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0Z73-0003Ec-9i for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 04:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Z72-0003ET-Kv for sip@ietf.org; Tue, 19 Jun 2007 04:30:56 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Z72-0003Nw-5s for sip@ietf.org; Tue, 19 Jun 2007 04:30:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5J8UqU2020834; Tue, 19 Jun 2007 11:30:53 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:30:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:30:44 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 11:30:44 +0300 Received: from [10.162.252.101] (essapo-nirac252101.europe.nokia.com [10.162.252.101]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5J8UgQU024189; Tue, 19 Jun 2007 11:30:43 +0300 Message-ID: <46779432.7040707@nokia.com> Date: Tue, 19 Jun 2007 11:30:42 +0300 From: Jari Urpalainen User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: "ext Sofie Lassborn (TN/EAB)" References: <3C26DE1DC0C6724B8928D40F216ECFB004C8928E@esealmw103.eemea.ericsson.se> In-Reply-To: <3C26DE1DC0C6724B8928D40F216ECFB004C8928E@esealmw103.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 08:30:44.0128 (UTC) FILETIME=[20D29A00:01C7B24C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: sip@ietf.org Subject: [Sip] Re: Questions on XCAP Diff Event draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org ext Sofie Lassborn (TN/EAB) wrote: > Hi Jari, > > I have some more questions regarding the last paragraph. Please see > below. > > Best regards, > Sofie > > > >> Chapter 4.7, second paragraph >> It is unclear to me what is meant by "...it MUST fall back to sending >> all component changes again for this resource." Is the intention that >> the server shall send a "full response" as in an initial notification >> (my preferred interpretation)? Or is the intention that the server >> shall send several notifications with the patches not aggregated? >> >> Best regards, >> Sofie >> >> > The latter, after sending the http reference, the server does not know > when the client has really read the content, thus no aggregation allowed > with "rapidly changing resources" > > [Sofie wrote:] > I see aggregation as very useful in conjuction with rate limitation and > throttle. An issue arrises though when a notification with aggregated > patches becomes too large. According to you the notifier should then > send all patches separately in several notifications but if rate > limitation or throttle is being used the client might never catch up. > Could it instead be the choise of the notifier if it wants to send a > notification with only the document link (content indirection) or if it > wants to send all patches separately? > > thanks, > Jari > Sorry, probably i've been unclear on this. Rate limitation/throttle combined with patching is indeed challenging but doable. And even you can combine filtering here in addition to standard authorization so the complexity begins to be quite high (although i could say that even the basic authorization handling is hard enough to implement, be it on server or client ;-)). So the notifier must be well aware of the client state all the time, it is not that one could simply drop some events, so "throttle engine" and patching process must co-operate properly. However, related to patching/syncing the key issue is that after the notifier sends only the http references, it doesn't have the knowledge when the client eventually has read the relevant resource content. So once the notifier does this reference sending, it fall backs into the "xml-patching" mode with full etag change history, i.e. aggregation _may_ cause similar trouble than during the initial sync. But subscription refresh (or versioning support in xcap server ;-)) would similarly solve this. But anyways, i think that i'll just submit a new version with some clarifications (and better examples) ? thanks, 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 sip-bounces@ietf.org Tue Jun 19 04:52:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZRP-0002tJ-G2; Tue, 19 Jun 2007 04:51:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ZRO-0002rC-9n for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 04:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZRN-0002r4-UE for sip@ietf.org; Tue, 19 Jun 2007 04:51:57 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZRN-0000bf-Hw for sip@ietf.org; Tue, 19 Jun 2007 04:51:57 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5J8pklg000982 for ; Tue, 19 Jun 2007 03:51:56 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 03:51:52 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:51:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Date: Tue, 19 Jun 2007 10:51:40 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180013036DF@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800128BE84@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 Thread-Index: Aceb9Ei0yMjSKfOKTL668b2fjJdKxgQNnWawAXIX61A= References: <5D1A7985295922448D5550C94DE29180011D3D10@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE291800128BE84@DEEXC1U01.de.lucent.com> From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" X-OriginalArrivalTime: 19 Jun 2007 08:51:40.0650 (UTC) FILETIME=[0DC4A4A0:01C7B24F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There were comments received on this draft, but none of them appear to be technical show stoppers. Volker will update the draft, based on the comments received. If any of these require technical discussion, he will raise the issues on the list. I do not expect any further WGLC. When the new version exists, I will submit a publication request to the IESG. For the related SIPPING drafts, these also received comments. Again none of these are technical show stoppers. There are also some issues with dependent references to be addressed. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith)=20 > Sent: Monday, June 11, 2007 2:18 PM > To: DRAGE, Keith (Keith); IETF SIP List > Subject: RE: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 >=20 > A further reminder that we would like comments on this WGLC=20 > by the end of today. >=20 > If you have comments, the please submit them. If you are=20 > likely to read this document then now would be a good time to=20 > complete that review. >=20 > Keith=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Monday, May 21, 2007 11:06 PM > > To: IETF SIP List > > Subject: [Sip] WGLC for draft-ietf-sip-session-policy-framework-01 > >=20 > > (As WG chair) > >=20 > > This is to announce a Working Group Last Call on > >=20 > > http://www.ietf.org/internet-drafts/draft-ietf-sip-session-pol > > icy-framew > > ork-01.txt > >=20 > > The WGLC is for 3 weeks and will end on 11th June 2007. > >=20 > > Please respond to the editor, and to the SIP mailing list with=20 > > comments. > >=20 > > This WGLC is being held in conjunction with the two related=20 > documents=20 > > in the SIPPING group, see mail below: > >=20 > > Regards > >=20 > > Keith > >=20 > > -------------------------------------------------------------- > > ---------- > > ----------------------------- > >=20 > > Hi all, > >=20 > > This is to announce Working Group Last Call on the following > > documents: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-p > > olicy-data > > set-04.txt (Recently updated to address the merging issue=20 > discussed=20 > > on the mailing list) > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy- > > package-03 > > .txt (Unchanged since prior to IETF-68) > >=20 > > This WGLC will end on 11 June 2007. > >=20 > > Since the WG has previously reviewed these documents, the=20 > plan is to=20 > > keep the same set of reviewers that previously > > volunteered:=20 > > Bob Penfield, Shida Schubert, Flemming Andreasen, Roni Even=20 > > However, anyone additional that would like to volunteer would be=20 > > appreciated to get a fresh set of eyes on the document. > >=20 > > Feedback should be sent to the authors' email addresses (which is=20 > > cc'ed using the tools alias in the above for your > > convenience) and please copy the SIPPING mailing list. =20 > >=20 > > Note: the original plan was to WGLC this set of documents=20 > along with=20 > > the framework document that moved to SIP. So, stay tuned for an=20 > > announcement on the SIP list of the WGLC plans for that document. > >=20 > > Thanks, > > Mary > > SIPPING WG co-chair > >=20 > > -------------------------------------------------------------- > > ---------- > > ------------------------------- > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 05:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aMK-0006hS-71; Tue, 19 Jun 2007 05:50:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0aMI-0006hI-3y for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 05:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aMH-0006h7-QS for sip@ietf.org; Tue, 19 Jun 2007 05:50:45 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0aME-0003zh-UT for sip@ietf.org; Tue, 19 Jun 2007 05:50:45 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5J9obTd006887; Tue, 19 Jun 2007 02:50:37 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5J9oaO2007782; Tue, 19 Jun 2007 02:50:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Sip] INFO usage (or not) Date: Tue, 19 Jun 2007 02:50:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7gABK58qQABYFnAAAc2ORt From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org By Internet, I mean a network of nodes with different implementations (vend= ors) across different administrative domains (service providers and enterpr= ises). If you have a Sonus softswitch talking to a Sonus softswitch life i= s good. If you have a Nortel softswitch talking to a Nortel softswitch life= is good. If you have a Cisco MGC talking to a Cisco MGC life is good.=20 If you want to mix and match, life is good for Acme and NexTone, to name a = few. AFAIK, only MSCML (RFC 4722) bothers to even try to negotiate content and u= nderstanding of the INFO messages.=20 I would very quickly concede that one could fix INFO. That was the point of= Dean's draft. However, I think it is way too late to go that route. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade:= see for what lemonade is. -----Original Message----- From: Christer Holmberg (JO/LMF) To: Eric Burger; sip@ietf.org Sent: Mon Jun 18 13:10:42 2007 Subject: RE: [Sip] INFO usage (or not) Hi,=20 >I agree: in a limited deployment scenario, like an=20 >application server connected to a media server using a yellow=20 >cable as a proxy and an application bought from a single=20 >systems integrator, there is no interoperability problem.=20 >However, the info incompatibility problem is real - I have=20 >experienced it in the wild. So, why don't you explain what problems you have seen? Because, I have seen implementations - from different vendors - working fin= e togheter. Of course, maybe there are also implementations which do NOT interop widely= , but they probably have been implemented without any use of the negotiatio= n mechanisms etc that we have in SIP, with a very limited deployment scope = in mind. There is not much we can do about that, but those kind of scenario= s are not what I have been talking about. =20 >You are correct in asserting that one can make INFO work - we=20 >were doing it in 2001. However, working in the Internet is a=20 >different case altoghether. What do you mean by "Internet"? Regards, Christer > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF) > To: Eric Burger; Keith Drage ; IETF=20 > SIP List > Sent: Mon Jun 18 02:19:55 2007 > Subject: RE: [Sip] INFO usage (or not) >=20 >=20 > Hi, >=20 > I am very concerned some some people use the word "newbies",=20 > and make it sound that people using INFO are beginners which=20 > have no clue about SIP. >=20 > Also, I have never heard about interoperability problems with=20 > INFO. One reason people are using INFO for certain things IS=20 > in order to interop with other implementations. >=20 > I am also confused that people seem to think that INFOs will=20 > start flying around for no reason, without the sender having=20 > any clue about whether the receiver will understand them or=20 > not. As we have discussed, there ARE mechanisms in SIP to=20 > negotiate what content types etc entities support. Yes, MAYBE=20 > we need to extend that (e.g. being able to indicate which=20 > methods can be used to carry a specific content type), if=20 > what we have is not enough. But, to me that is not the same=20 > thing has having "tons of problem". >=20 > Having said that, if there are issues with INFO, I have=20 > nothing against discussing them. But, if you are going to=20 > talk about alternative solutions, you also need to look at=20 > possible issues with those (having to set up multiple dialogs=20 > just in order to send some DTMFs associated with another dialog etc).=20 >=20 > We can sit in our meeting=20 > rooms and write whatever=20 > you-must-to-this-and-you-must-not-do-that documents, but if=20 > we don't care about the feedback we get from the real world=20 > OUTSIDE the meeting room it won't help much. In the long run=20 > it will cause more harm than good. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com] > > Sent: 17. kes=C3=A4kuuta 2007 12:53 > > To: Keith Drage; IETF SIP List > > Subject: Re: [Sip] INFO usage (or not) > >=20 > > How about this: > >=20 > > This document describes why the Session Initiation Protocol > > (SIP) INFO method, introduced in RFC 2976, has serious=20 > issues with any=20 > > use outside its use as a transport mechanism for ISDN User=20 > Part (ISUP)=20 > > call signaling in SIP-signaled networks. In the years since the=20 > > introduction of the INFO method, the IETF has published numerous,=20 > > interoperable extensions to SIP. > > This document explains why there are INFO-based,=20 > proprietary protocols=20 > > in the wild; the flaws of using INFO; and prescriptions for=20 > how to use=20 > > existing, interoperable SIP mechanisms to accomplish most=20 > any of these=20 > > tasks. > >=20 > >=20 > > My personal preference is for the document to be Standards=20 > Track and=20 > > be a Work Group chartered item. The reason is that for=20 > this document=20 > > to be useful, it MUST update RFC 2976. If it updates RFC=20 > 2976, then=20 > > newbies get the pointer when the download RFC 2976,=20 > pointing them to=20 > > this document, before they go off, create=20 > draft-mumble-foo-over-INFO,=20 > > and get flamed on the list. The essence of the normative=20 > content of=20 > > the document is, "one MUST NOT use INFO for anything other than=20 > > transporting ISUP or QSIG messages." > >=20 > > Because the normative content is so thin, I could understand not=20 > > saying that and making the document Informational (or BCP).=20 > However,=20 > > I really and truly believe that will significantly reduce=20 > the impact=20 > > the document will have. > >=20 > >=20 > > Outline: > > Introduction > > - Requirements for UA-to-UA signaling > > - The INFO method > > - The INFO method for ISUP signaling > > Issues with INFO > > - No or incomplete negotiation > > - No real identification of payload purpose on receipt=20 > Alternatives to=20 > > INFO > > - State Updates: SUBSCRIBE / NOTIFY > > - DTMF Transport: KPML (an example of state updates) > > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > > - Prescriptions for deciding which method is appropriate under what=20 > > circumstances Update to RFC 2976 > > - Limiting use of INFO to ISUP transport only Security=20 > Considerations > >=20 > >=20 > >=20 > >=20 > >=20 > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > > wrote: > >=20 > > > (As WG chair) > > >=20 > > > We have got a number of threads floating round on INFO > > usage, and it > > > would be nice to identify this into a potential body of > > work, and see > > > if there is support for it. > > >=20 > > > We have two previous drafts that never went anywhere, although=20 > > > contents of both carried support in the WG at the time: > > >=20 > > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > >=20 > > > The Session Initiation Protocol (SIP) INFO method > > defines a means for > > > transporting mid-dialog application layer data between > > user agents. > > > Its initial use was to support the transport of ISUP mid-call > > > messages which could not be mapped to any other SIP > > request method. > > > However, since its initial usage for that purpose,=20 > INFO has seen > > > widespread abuse as a means for introducing non-standard and > > > non-interoperable extensions to SIP. For this reason, > > we now believe > > > INFO should be considered harmful, and therefore, > > deprecated in its > > > current form. > > >=20 > > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > >=20 > > > The SIP INFO method (RFC 2976) establishes a method by which > > > applications may transfer application-specific > > information within a > > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > > describing and documenting an application of INFO, nor does it > > > provide a mechanism by which applications may negotiate > > such uses. > > > This document provides a framework for documenting and naming > > > specific uses of INFO (called INFO packages), for > > registering those > > > package names with IANA, and for negotiating the support > > for various > > > INFO packages between applications using SIP. > > >=20 > > > In the thread so far there have also been suggestions that cover: > > >=20 > > > - support to mediactrl for their discussion on requirements > > > - something for hitchhiker's guide to point to: > > > - something that answers all the questions that recur on > > this list on > > > INFO usage > > > - "I've been getting a lot of offline questions asking for > > the "right"=20 > > > way to carry information related to the session-usage (often=20 > > > information that's being tunneled around from companion or > > gatewayed > > > protocols)." > > > - INVITE dialog usage only, or already covered by RFC 2976 > > > - It would be OK with me if we ALSO had this type of > > guidance ("don't > > > look HERE, look over THERE") available ("stated strongly > > enough in an > > > easy to stumble across place"), but if coming up with=20 > that guidance=20 > > > takes more than about a week, I don't see a lot of reason > > to hold up > > > on "don't go there" > > > while we explore alternatives. > > > - INFO and DTMF > > > - XML payloads > > > - But people really need is guidance on when to use INFO, > > when to use > > > events, and when to use something entirely different. > > > - identification of purpose of info (Content-Type? - impacted by > > > multipart/mixed) > > > - any framework for control of usages (IANA registration? - RFC > > > 3427 update) > > >=20 > > > Would anybody out there like to have a go at drafting an > > abstract for > > > a potential WG deliverable (and also identifying level -=20 > Info, BCP,=20 > > > standards track) and submitting it to the list for discussion. > > > Remember an abstract needs to: > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > > ------- > > > Every RFC must have an Abstract section following the > > Copyright notice. > > > An Abstract will typically be 5-10 lines. An Abstract of > > more than 20 > > > lines is generally not acceptable. > > >=20 > > > The Abstract section should provide a concise and comprehensive=20 > > > overview of the purpose and contents of the entire > > document, to give a > > > technically knowledgeable reader a general overview of the > > function of > > > the document. In addition to its function in the RFC itself, the=20 > > > Abstract section text will appear in publication > > announcements and in > > > the online index of RFCs. > > >=20 > > > Composing a useful Abstract generally requires thought and care.=20 > > > Usually an Abstract should begin with a phrase like "This > > memo ..." or > > > "This document ...". A satisfactory abstract can often be > > constructed > > > in part from material within the Introduction section, but a good=20 > > > abstract will be shorter, less detailed, and perhaps > > broader in scope > > > than the Introduction. Simply copying and pasting the first few=20 > > > paragraphs of the Introduction is tempting, but it may=20 > result in an=20 > > > Abstract that is both incomplete and redundant. Note also that an=20 > > > Abstract is not a substitute for an Introduction; the RFC=20 > should be=20 > > > self-contained as if there were no Abstract section. > > >=20 > > > An Abstract should be complete in itself; it should not contain=20 > > > citations unless they are completely defined within the Abstract. > > > Abbreviations appearing in the Abstract should generally be > > expanded > > > in parentheses. There is a small set of reasonable > > exceptions to this > > > rule (see guidelines on abbreviations, above.) > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > > ------ > > >=20 > > > And as such should give a clear idea of whether there is > > anything we > > > should charter here or not. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > > Notice: This email message, together with any attachments, may=20 > > contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > > affiliated entities, that may be confidential, proprietary, =20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 Notice: This email message, together with any attachments, may contain inf= ormation of BEA Systems, Inc., its subsidiaries and affiliated entiti= es, that may be confidential, proprietary, copyrighted and/or legally p= rivileged, and is intended solely for the use of the individual or entity n= amed in this message. If you are not the intended recipient, and have recei= ved this message in error, please immediately return this by email and then= delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 06:09:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aeW-0006Z2-Um; Tue, 19 Jun 2007 06:09:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0aeV-0006Yk-DR for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 06:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0aeV-0006Yc-3e for sip@ietf.org; Tue, 19 Jun 2007 06:09:35 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0aeR-0000pK-QH for sip@ietf.org; Tue, 19 Jun 2007 06:09:35 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 204F820440; Tue, 19 Jun 2007 12:09:31 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-85-4677ab5ba93a Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id F0DD9201B1; Tue, 19 Jun 2007 12:09:30 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:09:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Tue, 19 Jun 2007 12:09:29 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705980474@esealmw113.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7gABK58qQABYFnAAAc2ORtAAByriA= References: From: "Christer Holmberg (JO/LMF)" To: "Eric Burger" , X-OriginalArrivalTime: 19 Jun 2007 10:09:30.0692 (UTC) FILETIME=[ED548040:01C7B259] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >By Internet, I mean a network of nodes with different=20 >implementations (vendors) across different administrative=20 >domains (service providers and enterprises). If you have a=20 >Sonus softswitch talking to a Sonus softswitch life is good.=20 >If you have a Nortel softswitch talking to a Nortel=20 >softswitch life is good. If you have a Cisco MGC talking to a=20 >Cisco MGC life is good.=20 For that you don't need to standardize anything. You don't even need = SIP. >If you want to mix and match, life is good for Acme and NexTone, to = name a few. I do want to mix - it's good for me too :) >AFAIK, only MSCML (RFC 4722) bothers to even try to negotiate=20 >content and understanding of the INFO messages.=20 >=20 >I would very quickly concede that one could fix INFO. That=20 >was the point of Dean's draft. However, I think it is way=20 >too late to go that route. I think it's way too late to start restricting the usage of INFO. I = agree that we should have fixed it earlier, so that people using INFO = would have some standard ground to stand on. Regards, Christer -- Mail sent from my desktop device - using INFO - and Eric is able to read = it :) And, we all need beer... =20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF) > To: Eric Burger; sip@ietf.org > Sent: Mon Jun 18 13:10:42 2007 > Subject: RE: [Sip] INFO usage (or not) >=20 >=20 > Hi,=20 >=20 > >I agree: in a limited deployment scenario, like an=20 > application server=20 > >connected to a media server using a yellow cable as a proxy and an=20 > >application bought from a single systems integrator, there is no=20 > >interoperability problem. > >However, the info incompatibility problem is real - I have=20 > experienced=20 > >it in the wild. >=20 > So, why don't you explain what problems you have seen? >=20 > Because, I have seen implementations - from different vendors=20 > - working fine togheter. >=20 > Of course, maybe there are also implementations which do NOT=20 > interop widely, but they probably have been implemented=20 > without any use of the negotiation mechanisms etc that we=20 > have in SIP, with a very limited deployment scope in mind.=20 > There is not much we can do about that, but those kind of=20 > scenarios are not what I have been talking about. > =20 > >You are correct in asserting that one can make INFO work - we were=20 > >doing it in 2001. However, working in the Internet is a=20 > different case=20 > >altoghether. >=20 > What do you mean by "Internet"? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > Sent from my wireless e-mail device. Sorry if terse. We all need=20 > > lemonade: see =20 > for what=20 > > lemonade is. > >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > To: Eric Burger; Keith Drage ;=20 > IETF SIP List=20 > > > > Sent: Mon Jun 18 02:19:55 2007 > > Subject: RE: [Sip] INFO usage (or not) > >=20 > >=20 > > Hi, > >=20 > > I am very concerned some some people use the word=20 > "newbies", and make=20 > > it sound that people using INFO are beginners which have no=20 > clue about=20 > > SIP. > >=20 > > Also, I have never heard about interoperability problems with INFO.=20 > > One reason people are using INFO for certain things IS in order to=20 > > interop with other implementations. > >=20 > > I am also confused that people seem to think that INFOs will start=20 > > flying around for no reason, without the sender having any=20 > clue about=20 > > whether the receiver will understand them or not. As we have=20 > > discussed, there ARE mechanisms in SIP to negotiate what=20 > content types=20 > > etc entities support. Yes, MAYBE we need to extend that (e.g. being=20 > > able to indicate which methods can be used to carry a=20 > specific content=20 > > type), if what we have is not enough. But, to me that is=20 > not the same=20 > > thing has having "tons of problem". > >=20 > > Having said that, if there are issues with INFO, I have nothing=20 > > against discussing them. But, if you are going to talk about=20 > > alternative solutions, you also need to look at possible=20 > issues with=20 > > those (having to set up multiple dialogs just in order to send some=20 > > DTMFs associated with another dialog etc). > >=20 > > We can sit in our meeting rooms=20 > > and write whatever you-must-to-this-and-you-must-not-do-that=20 > > documents, but if we don't care about the feedback we get from the=20 > > real world OUTSIDE the meeting room it won't help much. In the long=20 > > run it will cause more harm than good. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Eric Burger [mailto:eburger@bea.com] > > > Sent: 17. kes=E4kuuta 2007 12:53 > > > To: Keith Drage; IETF SIP List > > > Subject: Re: [Sip] INFO usage (or not) > > >=20 > > > How about this: > > >=20 > > > This document describes why the Session Initiation Protocol > > > (SIP) INFO method, introduced in RFC 2976, has serious > > issues with any > > > use outside its use as a transport mechanism for ISDN User > > Part (ISUP) > > > call signaling in SIP-signaled networks. In the years since the=20 > > > introduction of the INFO method, the IETF has published numerous,=20 > > > interoperable extensions to SIP. > > > This document explains why there are INFO-based, > > proprietary protocols > > > in the wild; the flaws of using INFO; and prescriptions for > > how to use > > > existing, interoperable SIP mechanisms to accomplish most > > any of these > > > tasks. > > >=20 > > >=20 > > > My personal preference is for the document to be Standards > > Track and > > > be a Work Group chartered item. The reason is that for > > this document > > > to be useful, it MUST update RFC 2976. If it updates RFC > > 2976, then > > > newbies get the pointer when the download RFC 2976, > > pointing them to > > > this document, before they go off, create > > draft-mumble-foo-over-INFO, > > > and get flamed on the list. The essence of the normative > > content of > > > the document is, "one MUST NOT use INFO for anything other than=20 > > > transporting ISUP or QSIG messages." > > >=20 > > > Because the normative content is so thin, I could understand not=20 > > > saying that and making the document Informational (or BCP). > > However, > > > I really and truly believe that will significantly reduce > > the impact > > > the document will have. > > >=20 > > >=20 > > > Outline: > > > Introduction > > > - Requirements for UA-to-UA signaling > > > - The INFO method > > > - The INFO method for ISUP signaling Issues with INFO > > > - No or incomplete negotiation > > > - No real identification of payload purpose on receipt > > Alternatives to > > > INFO > > > - State Updates: SUBSCRIBE / NOTIFY > > > - DTMF Transport: KPML (an example of state updates) > > > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > > > - Prescriptions for deciding which method is appropriate=20 > under what=20 > > > circumstances Update to RFC 2976 > > > - Limiting use of INFO to ISUP transport only Security > > Considerations > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > > > wrote: > > >=20 > > > > (As WG chair) > > > >=20 > > > > We have got a number of threads floating round on INFO > > > usage, and it > > > > would be nice to identify this into a potential body of > > > work, and see > > > > if there is support for it. > > > >=20 > > > > We have two previous drafts that never went anywhere, although=20 > > > > contents of both carried support in the WG at the time: > > > >=20 > > > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > > >=20 > > > > The Session Initiation Protocol (SIP) INFO method > > > defines a means for > > > > transporting mid-dialog application layer data between > > > user agents. > > > > Its initial use was to support the transport of ISUP mid-call > > > > messages which could not be mapped to any other SIP > > > request method. > > > > However, since its initial usage for that purpose, > > INFO has seen > > > > widespread abuse as a means for introducing non-standard and > > > > non-interoperable extensions to SIP. For this reason, > > > we now believe > > > > INFO should be considered harmful, and therefore, > > > deprecated in its > > > > current form. > > > >=20 > > > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > > >=20 > > > > The SIP INFO method (RFC 2976) establishes a method by which > > > > applications may transfer application-specific > > > information within a > > > > SIP dialog. However, RFC 2976 does not provide a=20 > mechanism for > > > > describing and documenting an application of INFO,=20 > nor does it > > > > provide a mechanism by which applications may negotiate > > > such uses. > > > > This document provides a framework for documenting and naming > > > > specific uses of INFO (called INFO packages), for > > > registering those > > > > package names with IANA, and for negotiating the support > > > for various > > > > INFO packages between applications using SIP. > > > >=20 > > > > In the thread so far there have also been suggestions=20 > that cover: > > > >=20 > > > > - support to mediactrl for their discussion on requirements > > > > - something for hitchhiker's guide to point to: > > > > - something that answers all the questions that recur on > > > this list on > > > > INFO usage > > > > - "I've been getting a lot of offline questions asking for > > > the "right"=20 > > > > way to carry information related to the session-usage (often=20 > > > > information that's being tunneled around from companion or > > > gatewayed > > > > protocols)." > > > > - INVITE dialog usage only, or already covered by RFC 2976 > > > > - It would be OK with me if we ALSO had this type of > > > guidance ("don't > > > > look HERE, look over THERE") available ("stated strongly > > > enough in an > > > > easy to stumble across place"), but if coming up with > > that guidance > > > > takes more than about a week, I don't see a lot of reason > > > to hold up > > > > on "don't go there" > > > > while we explore alternatives. > > > > - INFO and DTMF > > > > - XML payloads > > > > - But people really need is guidance on when to use INFO, > > > when to use > > > > events, and when to use something entirely different. > > > > - identification of purpose of info (Content-Type? - impacted by > > > > multipart/mixed) > > > > - any framework for control of usages (IANA registration? - RFC > > > > 3427 update) > > > >=20 > > > > Would anybody out there like to have a go at drafting an > > > abstract for > > > > a potential WG deliverable (and also identifying level - > > Info, BCP, > > > > standards track) and submitting it to the list for discussion. > > > > Remember an abstract needs to: > > > >=20 > > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > > -- > > > > ------- > > > > Every RFC must have an Abstract section following the > > > Copyright notice. > > > > An Abstract will typically be 5-10 lines. An Abstract of > > > more than 20 > > > > lines is generally not acceptable. > > > >=20 > > > > The Abstract section should provide a concise and comprehensive=20 > > > > overview of the purpose and contents of the entire > > > document, to give a > > > > technically knowledgeable reader a general overview of the > > > function of > > > > the document. In addition to its function in the RFC=20 > itself, the=20 > > > > Abstract section text will appear in publication > > > announcements and in > > > > the online index of RFCs. > > > >=20 > > > > Composing a useful Abstract generally requires thought=20 > and care.=20 > > > > Usually an Abstract should begin with a phrase like "This > > > memo ..." or > > > > "This document ...". A satisfactory abstract can often be > > > constructed > > > > in part from material within the Introduction section,=20 > but a good=20 > > > > abstract will be shorter, less detailed, and perhaps > > > broader in scope > > > > than the Introduction. Simply copying and pasting the first few=20 > > > > paragraphs of the Introduction is tempting, but it may > > result in an > > > > Abstract that is both incomplete and redundant. Note=20 > also that an=20 > > > > Abstract is not a substitute for an Introduction; the RFC > > should be > > > > self-contained as if there were no Abstract section. > > > >=20 > > > > An Abstract should be complete in itself; it should not contain=20 > > > > citations unless they are completely defined within the=20 > Abstract. > > > > Abbreviations appearing in the Abstract should generally be > > > expanded > > > > in parentheses. There is a small set of reasonable > > > exceptions to this > > > > rule (see guidelines on abbreviations, above.) > > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > > -- > > > > ------ > > > >=20 > > > > And as such should give a clear idea of whether there is > > > anything we > > > > should charter here or not. > > > >=20 > > > > Regards > > > >=20 > > > > Keith > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > >=20 > > > Notice: This email message, together with any attachments, may=20 > > > contain information of BEA Systems, Inc., its > > subsidiaries and > > > affiliated entities, that may be confidential, proprietary,=20 > > > copyrighted and/or legally privileged, and is intended > > solely for the > > > use of the individual or entity named in this message. If > > you are not > > > the intended recipient, and have received this message in error,=20 > > > please immediately return this by email and then delete it. > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 > > Notice: This email message, together with any attachments, may=20 > > contain information of BEA Systems, Inc., its=20 > subsidiaries and =20 > > affiliated entities, that may be confidential, proprietary, =20 > > copyrighted and/or legally privileged, and is intended=20 > solely for the=20 > > use of the individual or entity named in this message. If=20 > you are not=20 > > the intended recipient, and have received this message in error,=20 > > please immediately return this by email and then delete it. > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 06:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0afg-0000Yg-4M; Tue, 19 Jun 2007 06:10:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0afe-0000Wp-PJ for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 06:10:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0afe-0000Vo-EI for sip@ietf.org; Tue, 19 Jun 2007 06:10:46 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0afd-00016Y-V3 for sip@ietf.org; Tue, 19 Jun 2007 06:10:46 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJV0038KNYB8Q@szxga02-in.huawei.com> for sip@ietf.org; Tue, 19 Jun 2007 18:03:47 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJV00091NYA36@szxga02-in.huawei.com> for sip@ietf.org; Tue, 19 Jun 2007 18:03:47 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJV0001BNY7T6@szxml03-in.huawei.com> for sip@ietf.org; Tue, 19 Jun 2007 18:03:46 +0800 (CST) Date: Tue, 19 Jun 2007 18:03:44 +0800 From: Qian Sun To: sip@ietf.org Message-id: <001701c7b259$1ee36140$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AceyWR64eZdcllqSQqO91wyeMs55zQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Sip] Comments on draft-ietf-sip-multiple-refer-01.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Some comments on the draft... 1. I think it might be a good idea to talk something on "Referred-By" in = this draft. Referred-By mechanism is still very useful for the multiple = refer case. Maybe Refer-To related to a URI List with "bcc" or = "anonymize" is a trouble. "Referred-BY=E2=80=9D in the message header is = to identify the initial REFER-Issuer. This information may be encrypted = together with "refer-to" URI list, including the copy control level such = as to/cc/bcc to the end user, i.e. REFER-Target, where the information = will be decrypted by the REFER-Target. In this case the REFER-Recipient = won=E2=80=99t be able to get rid of the "bcc" URI from the URI list, and = the "bcc" URI will be sent to other REFER-Targets along with normal = to/cc. This will be a problem to destroy the blind cc function. However, the REFER-issuer may opt to not include a Referred-By token. = For example: REFER sip:conf-123@example.com;gruu;opaque=3Dhha9s8d-999a SIP/2.0 Refer-To: Referred-By: Carol Content-Type: application/resource-lists+xml Content-Disposition: recipient-list Content-Length: 362 Content-ID: When the URI list has no "bcc" or "anonymize" URI, REFER-issuer may = include the Referred-By token in the REFER body. 2. Nested refer in multiple refer is very interesting, I believe it = could be a good idea to enroll a "multiple nested refer" example into = this draft. Just for an example: REFER sip:list-service@example.com;gruu;opaque=3Dhha9s8d-999a = SIP/2.0 Refer-To: Content-ID: In this case, the REFER-Recipient acts as a Refer List service, has the = similar function to the MESSAGE List service, i.e. receives a REFER with = URI-List and distributes some REFERs to each address in the URI-List. Note that, there is only one final REFER-Target in above "nested = multiple refer" example, not multiple REFER-Targets. In some situations, = this convergent feature is useful. 3. I guess it might be a typo in Figure 2 "8. 200K OK", maybe you meant = "200 OK"? Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 08:23:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cjW-000681-L3; Tue, 19 Jun 2007 08:22:54 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0cjV-00067w-5T for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 08:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cjU-00067o-SB for sip@ietf.org; Tue, 19 Jun 2007 08:22:52 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cjT-0001Ks-D4 for sip@ietf.org; Tue, 19 Jun 2007 08:22:52 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 19 Jun 2007 14:22:48 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:22:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Sip] INFO and ISUP Date: Tue, 19 Jun 2007 14:22:47 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD4117672@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10E7A81F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO and ISUP Thread-Index: AcexNfesNm477B0pEdy0uwAWy4mm/wAkFlCAACl6M7A= From: "Jesske, R" To: , , X-OriginalArrivalTime: 19 Jun 2007 12:22:48.0192 (UTC) FILETIME=[8C362800:01C7B26C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org That is the problems with some RFC's because it is not stated for what = they are supposed or what people intended at that former times. And the text describing the procedures telling an other story... We have the same problems with RFC 3323 and 3325 for privacy purposes... Roland > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com]=20 > Gesendet: Montag, 18. Juni 2007 18:35 > An: Eric Burger; sip@ietf.org > Betreff: RE: [Sip] INFO and ISUP >=20 >=20 > Actually, it's not just ISUP. It's also QSIG. >=20 > But I agree, INFO was supposed to be be used only > for tunnelling legacy PSTN protocols between Media Gateway=20 > Controllers.=20 >=20 > > -----Original Message----- > > From: Eric Burger [mailto:eburger@bea.com]=20 > > Sent: Sunday, June 17, 2007 02:20 > > To: sip@ietf.org > > Subject: [Sip] INFO and ISUP > >=20 > > I cringe every time someone says, "The only acceptable use=20 > > for INFO is for ISUP." ALL of the arguments that apply to=20 > > "One cannot use INFO for foo" > > apply to why "One cannot use INFO for ISUP." > >=20 > > The INFO method is NOT to "carry [arbitrary] mid-session=20 > > information between SIP user agents" as RFC 2976 posits. The=20 > > one and only one reason one can use INFO for ISUP today is=20 > > because the method is ONLY defined for ISUP. > >=20 > > Said another way: the identifier 0x49 0x4E 0x46 0x4F has=20 > > *NOTHING* to do with INFO. It would have much better been=20 > > called 0x4E 0x53 0x55 0x50 (ISUP). > >=20 > > For legacy reasons, and because we really are talking about a=20 > > bunch of bits, not English, I would not offer we change the=20 > > name of the method. However, I would make it clear that the=20 > > method is NOT the general purpose method described in RFC 2976. > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip=20 > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 08:27:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cnY-0007qD-GO; Tue, 19 Jun 2007 08:27:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0cnW-0007ns-Ng for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 08:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cnW-0007jJ-8y for sip@ietf.org; Tue, 19 Jun 2007 08:27:02 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cnU-0002DG-ER for sip@ietf.org; Tue, 19 Jun 2007 08:27:02 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 19 Jun 2007 14:26:58 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:26:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Sip] INFO usage (or not) Date: Tue, 19 Jun 2007 14:26:57 +0200 Message-Id: <9886E5FCA6D76549A3011068483A4BD4117673@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASb2EAABI8VbQAJ+MYsA== From: "Jesske, R" To: , X-OriginalArrivalTime: 19 Jun 2007 12:26:58.0209 (UTC) FILETIME=[213BB910:01C7B26D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > Because RFC 2976 is wrong, and we are willing to correct our mistakes. = So lets start. But I'm not willing to restrict INFO to ISUP & QSIG MIME = only. BR Roland > -----Urspr=FCngliche Nachricht----- > Von: Eric Burger [mailto:eburger@bea.com]=20 > Gesendet: Montag, 18. Juni 2007 19:23 > An: Jesske, Roland; sip@ietf.org > Betreff: Re: AW: [Sip] INFO usage (or not) >=20 >=20 > Because RFC 2976 is wrong, and we are willing to correct our=20 > mistakes. Good news is that other than 3204, there are no=20 > documented standards track uses of INFO. There is one=20 > informational RFC that talks about its use in the wild (for=20 > media server control), but if you look at it (RFC 4722) you=20 > will see the #1 reason for using info was that in the day,=20 > there was no other alternative. >=20 > Given NO IETF standards use INFO, and we have been explaining=20 > why it is a bad idea for close to five years now, I do not=20 > see the problem with setting the record straight. >=20 > -- > Sent from my wireless e-mail device. Sorry if terse. We all=20 > need lemonade: see=20 > for what lemonade is. >=20 > -----Original Message----- > From: Jesske, R > To: Eric Burger; drage@alcatel-lucent.com=20 > ; sip@ietf.org > Sent: Mon Jun 18 02:01:29 2007 > Subject: AW: [Sip] INFO usage (or not) >=20 > Hi, > Why should be RFC's that are now 6 Years out in the world be=20 > restricted? > RFC 2976 clearly states for what INFO can be used. > I'm concerned about implementations that works with INFO=20 > regarding the rules defined within 2976. > Many implementations work based on that RFC. Like define a=20 > MIME, put it into INFO and it works. >=20 > I thought also that INFO was defined to put in some end to=20 > end information that shall be exchanged by UA's. > Why to restrict such a use in such a case? >=20 > If RFC 2976 will be changed is backward compatibility guaranteed? >=20 > Best Regards >=20 > Roland >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Eric Burger [mailto:eburger@bea.com]=20 > > Gesendet: Sonntag, 17. Juni 2007 11:53 > > An: Keith Drage; IETF SIP List > > Betreff: Re: [Sip] INFO usage (or not) > >=20 > >=20 > > How about this: > >=20 > > This document describes why the Session Initiation Protocol=20 > (SIP) INFO > > method, introduced in RFC 2976, has serious issues with any=20 > > use outside its > > use as a transport mechanism for ISDN User Part (ISUP) call=20 > > signaling in > > SIP-signaled networks. In the years since the introduction=20 > > of the INFO > > method, the IETF has published numerous, interoperable=20 > > extensions to SIP. > > This document explains why there are INFO-based, proprietary=20 > > protocols in > > the wild; the flaws of using INFO; and prescriptions for how to use > > existing, interoperable SIP mechanisms to accomplish most=20 > any of these > > tasks. > >=20 > >=20 > > My personal preference is for the document to be Standards=20 > > Track and be a > > Work Group chartered item. The reason is that for this=20 > document to be > > useful, it MUST update RFC 2976. If it updates RFC 2976,=20 > > then newbies get > > the pointer when the download RFC 2976, pointing them to this=20 > > document, > > before they go off, create draft-mumble-foo-over-INFO, and=20 > > get flamed on the > > list. The essence of the normative content of the document=20 > > is, "one MUST > > NOT use INFO for anything other than transporting ISUP or=20 > > QSIG messages." > >=20 > > Because the normative content is so thin, I could understand=20 > > not saying that > > and making the document Informational (or BCP). However, I=20 > > really and truly > > believe that will significantly reduce the impact the=20 > > document will have. > >=20 > >=20 > > Outline: > > Introduction > > - Requirements for UA-to-UA signaling > > - The INFO method > > - The INFO method for ISUP signaling > > Issues with INFO > > - No or incomplete negotiation > > - No real identification of payload purpose on receipt > > Alternatives to INFO > > - State Updates: SUBSCRIBE / NOTIFY > > - DTMF Transport: KPML (an example of state updates) > > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > > - Prescriptions for deciding which method is appropriate under what > > circumstances > > Update to RFC 2976 > > - Limiting use of INFO to ISUP transport only > > Security Considerations > >=20 > >=20 > >=20 > >=20 > >=20 > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)"=20 > > wrote: > >=20 > > > (As WG chair) > > >=20 > > > We have got a number of threads floating round on INFO=20 > usage, and it > > > would be nice to identify this into a potential body of=20 > > work, and see if > > > there is support for it. > > >=20 > > > We have two previous drafts that never went anywhere,=20 > > although contents > > > of both carried support in the WG at the time: > > >=20 > > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > >=20 > > > The Session Initiation Protocol (SIP) INFO method=20 > > defines a means for > > > transporting mid-dialog application layer data between=20 > > user agents. > > > Its initial use was to support the transport of ISUP mid-call > > > messages which could not be mapped to any other SIP=20 > > request method. > > > However, since its initial usage for that purpose,=20 > INFO has seen > > > widespread abuse as a means for introducing non-standard and > > > non-interoperable extensions to SIP. For this reason,=20 > > we now believe > > > INFO should be considered harmful, and therefore,=20 > > deprecated in its > > > current form. > > >=20 > > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > >=20 > > > The SIP INFO method (RFC 2976) establishes a method by which > > > applications may transfer application-specific=20 > > information within a > > > SIP dialog. However, RFC 2976 does not provide a mechanism for > > > describing and documenting an application of INFO, nor does it > > > provide a mechanism by which applications may negotiate=20 > > such uses. > > > This document provides a framework for documenting and naming > > > specific uses of INFO (called INFO packages), for=20 > > registering those > > > package names with IANA, and for negotiating the support=20 > > for various > > > INFO packages between applications using SIP. > > >=20 > > > In the thread so far there have also been suggestions that cover: > > >=20 > > > - support to mediactrl for their discussion on requirements > > > - something for hitchhiker's guide to point to: > > > - something that answers all the questions that recur on this list > > > on INFO usage > > > - "I've been getting a lot of offline questions asking for the > > > "right" way to carry information related to the=20 > session-usage (often > > > information that's being tunneled around from companion=20 > or gatewayed > > > protocols)." > > > - INVITE dialog usage only, or already covered by RFC 2976 > > > - It would be OK with me if we ALSO had this type of guidance > > > ("don't look HERE, look over THERE") available ("stated=20 > > strongly enough > > > in an easy to stumble across place"), but if coming up with that > > > guidance takes more than about a week, I don't see a lot of=20 > > reason to > > > hold up on "don't go there" > > > while we explore alternatives. > > > - INFO and DTMF > > > - XML payloads > > > - But people really need is guidance on when to use INFO, when to > > > use events, and when to use something entirely different. > > > - identification of purpose of info (Content-Type? - impacted by > > > multipart/mixed) > > > - any framework for control of usages (IANA registration? - RFC > > > 3427 update) > > >=20 > > > Would anybody out there like to have a go at drafting an=20 > > abstract for a > > > potential WG deliverable (and also identifying level - Info, BCP, > > > standards track) and submitting it to the list for=20 > > discussion. Remember > > > an abstract needs to: > > >=20 > > >=20 > > -------------------------------------------------------------- > > ---------- > > > ------- > > > Every RFC must have an Abstract section following the=20 > > Copyright notice. > > > An Abstract will typically be 5-10 lines. An Abstract of=20 > > more than 20 > > > lines is generally not acceptable. > > >=20 > > > The Abstract section should provide a concise and=20 > > comprehensive overview > > > of the purpose and contents of the entire document, to give a > > > technically knowledgeable reader a general overview of the=20 > > function of > > > the document. In addition to its function in the RFC itself, the > > > Abstract section text will appear in publication=20 > > announcements and in > > > the online index of RFCs. > > >=20 > > > Composing a useful Abstract generally requires thought and=20 > > care. Usually > > > an Abstract should begin with a phrase like "This memo=20 > ..." or "This > > > document ...". A satisfactory abstract can often be=20 > > constructed in part > > > from material within the Introduction section, but a good=20 > > abstract will > > > be shorter, less detailed, and perhaps broader in scope than the > > > Introduction. Simply copying and pasting the first few=20 > > paragraphs of the > > > Introduction is tempting, but it may result in an Abstract=20 > > that is both > > > incomplete and redundant. Note also that an Abstract is not=20 > > a substitute > > > for an Introduction; the RFC should be self-contained as if=20 > > there were > > > no Abstract section. > > >=20 > > > An Abstract should be complete in itself; it should not contain > > > citations unless they are completely defined within the Abstract. > > > Abbreviations appearing in the Abstract should generally be=20 > > expanded in > > > parentheses. There is a small set of reasonable exceptions=20 > > to this rule > > > (see guidelines on abbreviations, above.) > > >=20 > > -------------------------------------------------------------- > > ---------- > > > ------ > > >=20 > > > And as such should give a clear idea of whether there is=20 > anything we > > > should charter here or not. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > >=20 > >=20 > > Notice: This email message, together with any attachments,=20 > > may contain information of BEA Systems, Inc., its=20 > > subsidiaries and affiliated entities, that may be=20 > > confidential, proprietary, copyrighted and/or legally=20 > > privileged, and is intended solely for the use of the=20 > > individual or entity named in this message. If you are not=20 > > the intended recipient, and have received this message in=20 > > error, please immediately return this by email and then delete it. > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 09:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eAw-0001DV-F3; Tue, 19 Jun 2007 09:55:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0eAv-0001D9-2z for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 09:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eAu-0001D1-Pi for sip@ietf.org; Tue, 19 Jun 2007 09:55:16 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eAt-0007fD-Gc for sip@ietf.org; Tue, 19 Jun 2007 09:55:16 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5JDtDfR028079; Tue, 19 Jun 2007 08:55:13 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5JDtCa21161; Tue, 19 Jun 2007 08:55:13 -0500 (CDT) Message-ID: <4677E040.4040903@alcatel-lucent.com> Date: Tue, 19 Jun 2007 08:55:12 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > [JRE] I just don't get how this would work. The UAC receives only one > 2xx and as a result initiates one TLS handshake with the UAS concerned. > The UAC never gets to hear about any of the other forked-to UASs that > might have sent a 2xx, so can never establish a tunnel with those. Yes, that is correct. Simplicity at the UAC (i.e., does not have to deal with forking) at the risk of a sub-optimal rendezvous algorithm. I do not yet know whether this is a fair tradeoff or not. We could go the 4-way handshake that rfc3265 uses. Or simply bite the bullet as Paul and Francois suggest and mandate the UAC to handle multiple 3xx responses and leave the choice on whether or not to fork and how (serial, parallel) to it. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 10:04:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eK8-0002Jk-1E; Tue, 19 Jun 2007 10:04:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0eK6-0002Hv-2X for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:04:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eK5-0002Hi-Oo for sip@ietf.org; Tue, 19 Jun 2007 10:04:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eK0-0002PN-Va for sip@ietf.org; Tue, 19 Jun 2007 10:04:45 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 10:04:41 -0400 X-IronPort-AV: i="4.16,439,1175486400"; d="scan'208"; a="124018763:sNHT74119538" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JE4eOP015048; Tue, 19 Jun 2007 10:04:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5JE4e5h013876; Tue, 19 Jun 2007 14:04:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:04:34 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 10:04:34 -0400 Message-ID: <4677E270.9010509@cisco.com> Date: Tue, 19 Jun 2007 10:04:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: AW: AW: [Sip] INFO usage (or not) References: <9886E5FCA6D76549A3011068483A4BD4117673@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4117673@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jun 2007 14:04:34.0350 (UTC) FILETIME=[C3C3ECE0:01C7B27A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13880; t=1182261880; x=1183125880; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20AW=3A=20AW=3A=20[Sip]=20INFO=20usage=20(or=20not) |Sender:=20 |To:=20=22Jesske,=20R=22=20; bh=4JOvllkZmEqkB5M0cBl588lX+nZW9i/7iCmFvDAMZpE=; b=P+weC5L4nZSuufj4KmBg9KpYAJvIpCh7Zff21iIHBNg9SHQDnxoHOw4i+w36xCHqyADMnM/E +JilEa+TJtPfkCz6i98uMrYaaix3elVkQ7J5clLjMO8ygE60ctlgCOLm; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jesske, R wrote: >> Because RFC 2976 is wrong, and we are willing to correct our mistakes. > > So lets start. But I'm not willing to restrict INFO to ISUP & QSIG MIME only. There are a variety of things we could do, together or separately: 1)revise 2976 to restrict INFO to standardized usages. Make any other usage MUST NOT. 2)establish an IANA registry for uses of INFO based on Content-Type. It would define what information is needed to define a usage. Initially populate it with the existing standardized usages. The criteria for adding new uses could be: a) Stds track RFC b) Informational RFC c) FCFS 3)establish a policy that the WG won't approve any other usages of INFO, beyond the existing ISUP/QSIG ones. (Then we don't need a registry.) 4)do nothing - status quo. Existing uses IMO anything that bans the current practices (i.e. (1)) that haven't been standardized is futile - it won't cause them to stop. IMO we seem to have a significant majority in favor of (3), though apparently not a consensus. So I think the realistic possibilities are (2) or (4). And (2a) is pretty much the same as (1) so it isn't realistic either. One of the other variants of (2) could reflect the realities and improve on the current situation in that at least the existing usages would be documented in public. Paul > BR > > Roland > >> -----Ursprüngliche Nachricht----- >> Von: Eric Burger [mailto:eburger@bea.com] >> Gesendet: Montag, 18. Juni 2007 19:23 >> An: Jesske, Roland; sip@ietf.org >> Betreff: Re: AW: [Sip] INFO usage (or not) >> >> >> Because RFC 2976 is wrong, and we are willing to correct our >> mistakes. Good news is that other than 3204, there are no >> documented standards track uses of INFO. There is one >> informational RFC that talks about its use in the wild (for >> media server control), but if you look at it (RFC 4722) you >> will see the #1 reason for using info was that in the day, >> there was no other alternative. >> >> Given NO IETF standards use INFO, and we have been explaining >> why it is a bad idea for close to five years now, I do not >> see the problem with setting the record straight. >> >> -- >> Sent from my wireless e-mail device. Sorry if terse. We all >> need lemonade: see >> for what lemonade is. >> >> -----Original Message----- >> From: Jesske, R >> To: Eric Burger; drage@alcatel-lucent.com >> ; sip@ietf.org >> Sent: Mon Jun 18 02:01:29 2007 >> Subject: AW: [Sip] INFO usage (or not) >> >> Hi, >> Why should be RFC's that are now 6 Years out in the world be >> restricted? >> RFC 2976 clearly states for what INFO can be used. >> I'm concerned about implementations that works with INFO >> regarding the rules defined within 2976. >> Many implementations work based on that RFC. Like define a >> MIME, put it into INFO and it works. >> >> I thought also that INFO was defined to put in some end to >> end information that shall be exchanged by UA's. >> Why to restrict such a use in such a case? >> >> If RFC 2976 will be changed is backward compatibility guaranteed? >> >> Best Regards >> >> Roland >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Eric Burger [mailto:eburger@bea.com] >>> Gesendet: Sonntag, 17. Juni 2007 11:53 >>> An: Keith Drage; IETF SIP List >>> Betreff: Re: [Sip] INFO usage (or not) >>> >>> >>> How about this: >>> >>> This document describes why the Session Initiation Protocol >> (SIP) INFO >>> method, introduced in RFC 2976, has serious issues with any >>> use outside its >>> use as a transport mechanism for ISDN User Part (ISUP) call >>> signaling in >>> SIP-signaled networks. In the years since the introduction >>> of the INFO >>> method, the IETF has published numerous, interoperable >>> extensions to SIP. >>> This document explains why there are INFO-based, proprietary >>> protocols in >>> the wild; the flaws of using INFO; and prescriptions for how to use >>> existing, interoperable SIP mechanisms to accomplish most >> any of these >>> tasks. >>> >>> >>> My personal preference is for the document to be Standards >>> Track and be a >>> Work Group chartered item. The reason is that for this >> document to be >>> useful, it MUST update RFC 2976. If it updates RFC 2976, >>> then newbies get >>> the pointer when the download RFC 2976, pointing them to this >>> document, >>> before they go off, create draft-mumble-foo-over-INFO, and >>> get flamed on the >>> list. The essence of the normative content of the document >>> is, "one MUST >>> NOT use INFO for anything other than transporting ISUP or >>> QSIG messages." >>> >>> Because the normative content is so thin, I could understand >>> not saying that >>> and making the document Informational (or BCP). However, I >>> really and truly >>> believe that will significantly reduce the impact the >>> document will have. >>> >>> >>> Outline: >>> Introduction >>> - Requirements for UA-to-UA signaling >>> - The INFO method >>> - The INFO method for ISUP signaling >>> Issues with INFO >>> - No or incomplete negotiation >>> - No real identification of payload purpose on receipt >>> Alternatives to INFO >>> - State Updates: SUBSCRIBE / NOTIFY >>> - DTMF Transport: KPML (an example of state updates) >>> - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP >>> - Prescriptions for deciding which method is appropriate under what >>> circumstances >>> Update to RFC 2976 >>> - Limiting use of INFO to ISUP transport only >>> Security Considerations >>> >>> >>> >>> >>> >>> On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)" >>> wrote: >>> >>>> (As WG chair) >>>> >>>> We have got a number of threads floating round on INFO >> usage, and it >>>> would be nice to identify this into a potential body of >>> work, and see if >>>> there is support for it. >>>> >>>> We have two previous drafts that never went anywhere, >>> although contents >>>> of both carried support in the WG at the time: >>>> >>>> http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 >>>> >>>> The Session Initiation Protocol (SIP) INFO method >>> defines a means for >>>> transporting mid-dialog application layer data between >>> user agents. >>>> Its initial use was to support the transport of ISUP mid-call >>>> messages which could not be mapped to any other SIP >>> request method. >>>> However, since its initial usage for that purpose, >> INFO has seen >>>> widespread abuse as a means for introducing non-standard and >>>> non-interoperable extensions to SIP. For this reason, >>> we now believe >>>> INFO should be considered harmful, and therefore, >>> deprecated in its >>>> current form. >>>> >>>> http://tools.ietf.org/html/draft-willis-sip-infopackage-00 >>>> >>>> The SIP INFO method (RFC 2976) establishes a method by which >>>> applications may transfer application-specific >>> information within a >>>> SIP dialog. However, RFC 2976 does not provide a mechanism for >>>> describing and documenting an application of INFO, nor does it >>>> provide a mechanism by which applications may negotiate >>> such uses. >>>> This document provides a framework for documenting and naming >>>> specific uses of INFO (called INFO packages), for >>> registering those >>>> package names with IANA, and for negotiating the support >>> for various >>>> INFO packages between applications using SIP. >>>> >>>> In the thread so far there have also been suggestions that cover: >>>> >>>> - support to mediactrl for their discussion on requirements >>>> - something for hitchhiker's guide to point to: >>>> - something that answers all the questions that recur on this list >>>> on INFO usage >>>> - "I've been getting a lot of offline questions asking for the >>>> "right" way to carry information related to the >> session-usage (often >>>> information that's being tunneled around from companion >> or gatewayed >>>> protocols)." >>>> - INVITE dialog usage only, or already covered by RFC 2976 >>>> - It would be OK with me if we ALSO had this type of guidance >>>> ("don't look HERE, look over THERE") available ("stated >>> strongly enough >>>> in an easy to stumble across place"), but if coming up with that >>>> guidance takes more than about a week, I don't see a lot of >>> reason to >>>> hold up on "don't go there" >>>> while we explore alternatives. >>>> - INFO and DTMF >>>> - XML payloads >>>> - But people really need is guidance on when to use INFO, when to >>>> use events, and when to use something entirely different. >>>> - identification of purpose of info (Content-Type? - impacted by >>>> multipart/mixed) >>>> - any framework for control of usages (IANA registration? - RFC >>>> 3427 update) >>>> >>>> Would anybody out there like to have a go at drafting an >>> abstract for a >>>> potential WG deliverable (and also identifying level - Info, BCP, >>>> standards track) and submitting it to the list for >>> discussion. Remember >>>> an abstract needs to: >>>> >>>> >>> -------------------------------------------------------------- >>> ---------- >>>> ------- >>>> Every RFC must have an Abstract section following the >>> Copyright notice. >>>> An Abstract will typically be 5-10 lines. An Abstract of >>> more than 20 >>>> lines is generally not acceptable. >>>> >>>> The Abstract section should provide a concise and >>> comprehensive overview >>>> of the purpose and contents of the entire document, to give a >>>> technically knowledgeable reader a general overview of the >>> function of >>>> the document. In addition to its function in the RFC itself, the >>>> Abstract section text will appear in publication >>> announcements and in >>>> the online index of RFCs. >>>> >>>> Composing a useful Abstract generally requires thought and >>> care. Usually >>>> an Abstract should begin with a phrase like "This memo >> ..." or "This >>>> document ...". A satisfactory abstract can often be >>> constructed in part >>>> from material within the Introduction section, but a good >>> abstract will >>>> be shorter, less detailed, and perhaps broader in scope than the >>>> Introduction. Simply copying and pasting the first few >>> paragraphs of the >>>> Introduction is tempting, but it may result in an Abstract >>> that is both >>>> incomplete and redundant. Note also that an Abstract is not >>> a substitute >>>> for an Introduction; the RFC should be self-contained as if >>> there were >>>> no Abstract section. >>>> >>>> An Abstract should be complete in itself; it should not contain >>>> citations unless they are completely defined within the Abstract. >>>> Abbreviations appearing in the Abstract should generally be >>> expanded in >>>> parentheses. There is a small set of reasonable exceptions >>> to this rule >>>> (see guidelines on abbreviations, above.) >>>> >>> -------------------------------------------------------------- >>> ---------- >>>> ------ >>>> >>>> And as such should give a clear idea of whether there is >> anything we >>>> should charter here or not. >>>> >>>> Regards >>>> >>>> Keith >>>> >>>> >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the >> application of sip >>> >>> Notice: This email message, together with any attachments, >>> may contain information of BEA Systems, Inc., its >>> subsidiaries and affiliated entities, that may be >>> confidential, proprietary, copyrighted and/or legally >>> privileged, and is intended solely for the use of the >>> individual or entity named in this message. If you are not >>> the intended recipient, and have received this message in >>> error, please immediately return this by email and then delete it. >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> Notice: This email message, together with any attachments, >> may contain information of BEA Systems, Inc., its >> subsidiaries and affiliated entities, that may be >> confidential, proprietary, copyrighted and/or legally >> privileged, and is intended solely for the use of the >> individual or entity named in this message. If you are not >> the intended recipient, and have received this message in >> error, please immediately return this by email and then delete it. >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 10:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eyZ-0000hF-Lh; Tue, 19 Jun 2007 10:46:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0eyY-0000h8-C4 for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 10:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eyY-0000gP-25 for sip@ietf.org; Tue, 19 Jun 2007 10:46:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0eyW-00068K-OP for sip@ietf.org; Tue, 19 Jun 2007 10:46:34 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I0eyT-0001o5-14; Tue, 19 Jun 2007 09:46:29 -0500 In-Reply-To: <46772959.5010407@alcatel-lucent.com> References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58128EC2-8375-4EA7-9EE6-8615ECC8BD82@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 09:46:10 -0500 To: Vijay K. Gurbani X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IETF SIP List , Paul Kyzivat , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 18, 2007, at 7:54 PM, Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> True. But how many UAs support sipsec? :-) > > Touche! Nothing like reality biting back in the face. ;-) > > So let's think this through. Francois suggested proxies > don't fork and return 3xx, possibly with multiple contacts > and let the UAC decide if it wants to fork. > > This is certainly possible, although having implemented forking > and response aggregation in a SIP stack, I know that this is a > non-trivial amount of complexity that now every UA would have > to implement if it wants to support sipsec. > > Now, one thing that we have discovered that is sub-optimal about > proxies that recurse instead of sending a 3xx to the UA is the > potential for upgrading a sip URI to sips and downgrading in > reverse. With sipsec, such upgrading or downgrading at proxies > does not matter. Eventually, over any transport (sip or sips) > chosen by the proxy, certs would be exchanged end-to-end. For > this reason, it would be good if we don't force the endpoint > to support forking. > > And finally, forking a non-INVITE request at a proxy should > still result in one 2xx, or a best non-2xx being returned to > the UAC. So user agents can inherit much of the current > transaction-related behavior for CONNECT and augment it with > the certificate and tunnel behavior. There's no real reason you couldn't for a CONNECT. The UA is still going to have to decide which endpoint it upgrades to TLS. Although in the absence of a PKI, the connected-surprise problem could become an issue. This is a somewhat more tractable problem if 302 is issued, as the UA would only exercise contacts in the 302 which it expects to be able to validate. -- 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 sip-bounces@ietf.org Tue Jun 19 11:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0frA-0001MY-T1; Tue, 19 Jun 2007 11:43:00 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0fr9-0001MQ-5g for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fr8-0001MI-SJ for sip@ietf.org; Tue, 19 Jun 2007 11:42:58 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fr8-00042P-Cb for sip@ietf.org; Tue, 19 Jun 2007 11:42:58 -0400 Received: from [172.17.2.60] ([172.17.2.60]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l5JFgov6038832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 19 Jun 2007 10:42:50 -0500 (CDT) (envelope-from bcampen@estacado.net) In-Reply-To: <000301c79f3f$f7330320$3f91460a@china.huawei.com> References: <000301c79f3f$f7330320$3f91460a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Byron Campen Subject: Re: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 (2006-07)] Date: Tue, 19 Jun 2007 10:42:48 -0500 To: Lavis Chow X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0118995285==" Errors-To: sip-bounces@ietf.org --===============0118995285== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12--50375061; protocol="application/pkcs7-signature" --Apple-Mail-12--50375061 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed If the original BYE had a magic cookie, then a second BYE _without_ it is a new transaction (the language in 3261 doesn't say this explicitly, but it is assumed that a UAC would not send one BYE with a magic cookie, and a retransmission without). Additionally, since we compare the topmost Via in the 2543 tid case, changing the branch param between the two BYEs will also cause the match to fail. This test case is incorrect. Best regards, Byron Campen > > Not sure the purpose is the "Purpose" list in the test case or for > 2543 > test? > > But the [Ref] listed in the test case is reference to RFC3261. > > And for RFC2543(not bis02 afterwards) server, it didn't check the > Via for > the request matching transaction at all. > > Lavis > > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] > Sent: Saturday, May 26, 2007 5:24 AM > To: sip@ietf.org > Subject: Re: [Sip] Query about test case in [ETSI TS 102 027-2 V4.1.1 > (2006-07)] > > From: Lavis Chow > > Purpose: Ensure that the IUT in a server BYE Proceeding state, > on receipt > of > a BYE request, including a Via header set with a different branch > parameter > without the magic cookie "z9hG4bK" but with the Request-URI, To > tag, From > tag, Call-ID, CSeq and top Via header identical as in the first BYE > request, > repeats its last response. > > Since "z9hG4bK" is not to be present, it may be testing RFC 2543 > behavior. > Does this test make sense in that light? > > Dale > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed > above. Any > use of the > information contained herein in any way (including, but not limited > to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, > please > notify the sender by > phone or email immediately and delete it! > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-12--50375061 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGKTCCAuIw ggJLoAMCAQICEAda7Ce+sudhzrOd9CS5wJQwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDkyNTE0NDUzNloXDTA3MDkyNTE0NDUz NlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWxjwykU0M R1yTjA3db2wzExKsMhLa/mc2ekFkBP9BVXi4OHacKSZM3a9T0bWvPcw97ycBfDZX3q2prMRsPUep svJWA0wbiWyOtLzuQGWaQQ6rYbvYlRxil/teAJb1fAKdfFXIXXsiqcdHkhbFn/J7oSn1BCz6v9/v M1zgGNeMPIR34bo9A0hW+QZJxwkSg4KZHdaQ50WcKXtdHdBg46s+0bvDqNmmt7eP91UJk9aiyxyw ZdWVNxzF1oj+nfsnsaHv1py6l62Je82mHsvIZwdSAic1PtXVpU8QmkLJHPmkBEVtN/uHMQ95xgxi eFO5hbYuAT9f7V0ZGe7pUJBR3KwdAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGJjYW1wZW5AZXN0YWNh ZG8ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAeJC75lz4KrtNdPOovb3fkqzD i2HXuOtYHCTOPMc5xJGLdqSF5sc8bwd4mIfevi9Ji4Ccj85A6qINQM/v4OjAvxPkwRwXey/YN6kl 19Te3Eh/t9l4zo2wPdbHTipyc8YJ0GAtT4/fwWiboW3+aquk8DGc7ityr9cdAYY1jAud7d0wggM/ MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWls QHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO 3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gE f6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNy bDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYv wPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bG CE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAda7Ce+sudhzrOd9CS5wJQwCQYFKw4D AhoFAKCCAW8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE5 MTU0MjQ4WjAjBgkqhkiG9w0BCQQxFgQUfVpMitKC/49BrPGcHmPAOLUmdPIwgYUGCSsGAQQBgjcQ BDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHWuwnvrLn Yc6znfQkucCUMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhAHWuwnvrLnYc6znfQkucCUMA0GCSqGSIb3DQEBAQUABIIBAE67tl6G qbjJxxvzsdiHT79hShbAvhPRGXEFOFEtJyoFwvsSzavaPk96x9TywJQzh1khJUzSd1RS/YT4R60/ Z1U6nobDOk1vQGAlaBzEwh1i6dlA3/xgVRK/+TX9nob8TdF0SObH5AD5NykErhRL35WVhMHXGd/6 U9IwbLiOvZ4N6j4shKPjnaw/OwE/b+k9YvPe+RUpZiArCqoxXbfsc1pURxTKHO1Svdn1+3pH6m9x sjW9GfyBaX/hn9DM42IXP6HjhXpKxepvy0DhDHWFV348FF/ENYQEpeOSMArEjk1QJGSMtBnETeSd d/MyhN3a/VoTpnZ9687rnIuzryBE3wcAAAAAAAA= --Apple-Mail-12--50375061-- --===============0118995285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0118995285==-- From sip-bounces@ietf.org Tue Jun 19 11:47:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fv9-0002x1-A4; Tue, 19 Jun 2007 11:47:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0fv8-0002uF-6A for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fv7-0002u4-Rz for sip@ietf.org; Tue, 19 Jun 2007 11:47:05 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fv5-0005Rc-Ka for sip@ietf.org; Tue, 19 Jun 2007 11:47:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JFl0m23361; Tue, 19 Jun 2007 15:47:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 10:46:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3405@zrc2hxm0.corp.nortel.com> In-Reply-To: <58128EC2-8375-4EA7-9EE6-8615ECC8BD82@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceygKFMNp/32OBQRbiwnSxH7zby+gACGEqQ References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <58128EC2-8375-4EA7-9EE6-8615ECC8BD82@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 > > And finally, forking a non-INVITE request at a proxy should still=20 > > result in one 2xx, or a best non-2xx being returned to the UAC. So=20 > > user agents can inherit much of the current transaction-related=20 > > behavior for CONNECT and augment it with the certificate and tunnel=20 > > behavior. >=20 > There's no real reason you couldn't for a CONNECT. The UA is=20 > still going to have to decide which endpoint it upgrades to=20 > TLS. Although in the absence of a PKI, the connected-surprise=20 > problem could become an issue. This is a somewhat more=20 > tractable problem if 302 is issued, as the UA would only=20 > exercise contacts in the 302 which it expects to be able to validate. I agree with Dean. In fact, that's what I tought we were talking about. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 11:52:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g00-0008WV-Dl; Tue, 19 Jun 2007 11:52:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0fzz-0008TC-1O for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 11:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fzy-0008T4-O3 for sip@ietf.org; Tue, 19 Jun 2007 11:52:06 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fzx-00070a-Eo for sip@ietf.org; Tue, 19 Jun 2007 11:52:06 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JFpvr22401; Tue, 19 Jun 2007 15:51:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 10:51:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceyDIhel7LNZ5MhT6ivddc9myYEEwAMapSwABK6uNA= References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Vijay K. Gurbani" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Agreed. Basically, say the "CONNECT" ended up in 3 different directions after a 3XX with 3 contacts. The UAC would set up the end-to-end TLS connections from the UAC to the 3 contacts. Then the INVITEs have no intermediaries, so they can't fork. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Monday, June 18, 2007 23:53 > To: Vijay K. Gurbani; Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: IETF SIP List > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 >=20 > Vijay,=20 >=20 > > And finally, forking a non-INVITE request at a proxy should still=20 > > result in one 2xx, or a best non-2xx being returned to the UAC. So=20 > > user agents can inherit much of the current transaction-related=20 > > behavior for CONNECT and augment it with the certificate and tunnel=20 > > behavior. > [JRE] I just don't get how this would work. The UAC receives=20 > only one 2xx and as a result initiates one TLS handshake with=20 > the UAS concerned. > The UAC never gets to hear about any of the other forked-to=20 > UASs that might have sent a 2xx, so can never establish a=20 > tunnel with those. >=20 > John >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 12:20:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gRr-0005ci-4o; Tue, 19 Jun 2007 12:20:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0gRp-0005cc-NF for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gRp-0005cU-DS for sip@ietf.org; Tue, 19 Jun 2007 12:20:53 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gRn-0005VY-HB for sip@ietf.org; Tue, 19 Jun 2007 12:20:53 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by smtpa.juniper.net with ESMTP; 19 Jun 2007 09:20:50 -0700 X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="21579958:sNHT69785392" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jun 2007 17:20:49 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Subject: RE: AW: AW: [Sip] INFO usage (or not) Date: Tue, 19 Jun 2007 17:20:47 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A53EE4@EMAILEMEA3.jnpr.net> In-Reply-To: <4677E270.9010509@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [Sip] INFO usage (or not) Thread-Index: AceyeuevXuR3g3faQ+W94qsCpdfFXQADwUfA References: <9886E5FCA6D76549A3011068483A4BD4117673@S4DE8PSAAQB.mitte.t-com.de> <4677E270.9010509@cisco.com> From: "Gilad Shaham" To: "Paul Kyzivat" , "Jesske, R" X-OriginalArrivalTime: 19 Jun 2007 16:20:49.0487 (UTC) FILETIME=[CC86D5F0:01C7B28D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org There are also issues on whether or not the allowed/desired INFO types = should be specified somewhere. Furthermore, whether or not content-type is good enough for INFO type is = not a consensus either. If there are too many misuses (or abuses) of INFO then we need to = realize if it's due to lack of INFO understanding or lack of defined = functionality. We should map these cases. So far I have not seen many = claims that INFO is required for something specific, either because most = implementers do not use it or because it is deemed so unworthy in these = discussions that people are shy. My personal feeling is that INFO is too broken to be fixed at this = point. If implementers used INFO to solve issues, in a way that seems as = if INFO should not be used in a normative RFC, then we should think of = alternative solutions. However, I might change my mind if I see good = usages of INFO. Gilad > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 19, 2007 5:05 PM > To: Jesske, R > Cc: sip@ietf.org > Subject: Re: AW: AW: [Sip] INFO usage (or not) >=20 >=20 >=20 > Jesske, R wrote: > >> Because RFC 2976 is wrong, and we are willing to correct our = mistakes. > > > > So lets start. But I'm not willing to restrict INFO to ISUP & QSIG = MIME > only. >=20 > There are a variety of things we could do, together or separately: >=20 > 1)revise 2976 to restrict INFO to standardized usages. Make any other > usage MUST NOT. >=20 > 2)establish an IANA registry for uses of INFO based on Content-Type. > It would define what information is needed to define a usage. > Initially populate it with the existing standardized usages. > The criteria for adding new uses could be: > a) Stds track RFC > b) Informational RFC > c) FCFS >=20 > 3)establish a policy that the WG won't approve any other usages of = INFO, > beyond the existing ISUP/QSIG ones. (Then we don't need a = registry.) >=20 > 4)do nothing - status quo. Existing uses >=20 > IMO anything that bans the current practices (i.e. (1)) that haven't > been standardized is futile - it won't cause them to stop. IMO we seem > to have a significant majority in favor of (3), though apparently not = a > consensus. >=20 > So I think the realistic possibilities are (2) or (4). And (2a) is > pretty much the same as (1) so it isn't realistic either. >=20 > One of the other variants of (2) could reflect the realities and = improve > on the current situation in that at least the existing usages would be > documented in public. >=20 > Paul >=20 > > BR > > > > Roland > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Eric Burger [mailto:eburger@bea.com] > >> Gesendet: Montag, 18. Juni 2007 19:23 > >> An: Jesske, Roland; sip@ietf.org > >> Betreff: Re: AW: [Sip] INFO usage (or not) > >> > >> > >> Because RFC 2976 is wrong, and we are willing to correct our > >> mistakes. Good news is that other than 3204, there are no > >> documented standards track uses of INFO. There is one > >> informational RFC that talks about its use in the wild (for > >> media server control), but if you look at it (RFC 4722) you > >> will see the #1 reason for using info was that in the day, > >> there was no other alternative. > >> > >> Given NO IETF standards use INFO, and we have been explaining > >> why it is a bad idea for close to five years now, I do not > >> see the problem with setting the record straight. > >> > >> -- > >> Sent from my wireless e-mail device. Sorry if terse. We all > >> need lemonade: see > >> for what lemonade is. > >> > >> -----Original Message----- > >> From: Jesske, R > >> To: Eric Burger; drage@alcatel-lucent.com > >> ; sip@ietf.org > >> Sent: Mon Jun 18 02:01:29 2007 > >> Subject: AW: [Sip] INFO usage (or not) > >> > >> Hi, > >> Why should be RFC's that are now 6 Years out in the world be > >> restricted? > >> RFC 2976 clearly states for what INFO can be used. > >> I'm concerned about implementations that works with INFO > >> regarding the rules defined within 2976. > >> Many implementations work based on that RFC. Like define a > >> MIME, put it into INFO and it works. > >> > >> I thought also that INFO was defined to put in some end to > >> end information that shall be exchanged by UA's. > >> Why to restrict such a use in such a case? > >> > >> If RFC 2976 will be changed is backward compatibility guaranteed? > >> > >> Best Regards > >> > >> Roland > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: Eric Burger [mailto:eburger@bea.com] > >>> Gesendet: Sonntag, 17. Juni 2007 11:53 > >>> An: Keith Drage; IETF SIP List > >>> Betreff: Re: [Sip] INFO usage (or not) > >>> > >>> > >>> How about this: > >>> > >>> This document describes why the Session Initiation Protocol > >> (SIP) INFO > >>> method, introduced in RFC 2976, has serious issues with any > >>> use outside its > >>> use as a transport mechanism for ISDN User Part (ISUP) call > >>> signaling in > >>> SIP-signaled networks. In the years since the introduction > >>> of the INFO > >>> method, the IETF has published numerous, interoperable > >>> extensions to SIP. > >>> This document explains why there are INFO-based, proprietary > >>> protocols in > >>> the wild; the flaws of using INFO; and prescriptions for how to = use > >>> existing, interoperable SIP mechanisms to accomplish most > >> any of these > >>> tasks. > >>> > >>> > >>> My personal preference is for the document to be Standards > >>> Track and be a > >>> Work Group chartered item. The reason is that for this > >> document to be > >>> useful, it MUST update RFC 2976. If it updates RFC 2976, > >>> then newbies get > >>> the pointer when the download RFC 2976, pointing them to this > >>> document, > >>> before they go off, create draft-mumble-foo-over-INFO, and > >>> get flamed on the > >>> list. The essence of the normative content of the document > >>> is, "one MUST > >>> NOT use INFO for anything other than transporting ISUP or > >>> QSIG messages." > >>> > >>> Because the normative content is so thin, I could understand > >>> not saying that > >>> and making the document Informational (or BCP). However, I > >>> really and truly > >>> believe that will significantly reduce the impact the > >>> document will have. > >>> > >>> > >>> Outline: > >>> Introduction > >>> - Requirements for UA-to-UA signaling > >>> - The INFO method > >>> - The INFO method for ISUP signaling > >>> Issues with INFO > >>> - No or incomplete negotiation > >>> - No real identification of payload purpose on receipt > >>> Alternatives to INFO > >>> - State Updates: SUBSCRIBE / NOTIFY > >>> - DTMF Transport: KPML (an example of state updates) > >>> - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > >>> - Prescriptions for deciding which method is appropriate under = what > >>> circumstances > >>> Update to RFC 2976 > >>> - Limiting use of INFO to ISUP transport only > >>> Security Considerations > >>> > >>> > >>> > >>> > >>> > >>> On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)" > >>> wrote: > >>> > >>>> (As WG chair) > >>>> > >>>> We have got a number of threads floating round on INFO > >> usage, and it > >>>> would be nice to identify this into a potential body of > >>> work, and see if > >>>> there is support for it. > >>>> > >>>> We have two previous drafts that never went anywhere, > >>> although contents > >>>> of both carried support in the WG at the time: > >>>> > >>>> http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > >>>> > >>>> The Session Initiation Protocol (SIP) INFO method > >>> defines a means for > >>>> transporting mid-dialog application layer data between > >>> user agents. > >>>> Its initial use was to support the transport of ISUP mid-call > >>>> messages which could not be mapped to any other SIP > >>> request method. > >>>> However, since its initial usage for that purpose, > >> INFO has seen > >>>> widespread abuse as a means for introducing non-standard and > >>>> non-interoperable extensions to SIP. For this reason, > >>> we now believe > >>>> INFO should be considered harmful, and therefore, > >>> deprecated in its > >>>> current form. > >>>> > >>>> http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > >>>> > >>>> The SIP INFO method (RFC 2976) establishes a method by which > >>>> applications may transfer application-specific > >>> information within a > >>>> SIP dialog. However, RFC 2976 does not provide a mechanism = for > >>>> describing and documenting an application of INFO, nor does it > >>>> provide a mechanism by which applications may negotiate > >>> such uses. > >>>> This document provides a framework for documenting and naming > >>>> specific uses of INFO (called INFO packages), for > >>> registering those > >>>> package names with IANA, and for negotiating the support > >>> for various > >>>> INFO packages between applications using SIP. > >>>> > >>>> In the thread so far there have also been suggestions that cover: > >>>> > >>>> - support to mediactrl for their discussion on requirements > >>>> - something for hitchhiker's guide to point to: > >>>> - something that answers all the questions that recur on this = list > >>>> on INFO usage > >>>> - "I've been getting a lot of offline questions asking for the > >>>> "right" way to carry information related to the > >> session-usage (often > >>>> information that's being tunneled around from companion > >> or gatewayed > >>>> protocols)." > >>>> - INVITE dialog usage only, or already covered by RFC 2976 > >>>> - It would be OK with me if we ALSO had this type of guidance > >>>> ("don't look HERE, look over THERE") available ("stated > >>> strongly enough > >>>> in an easy to stumble across place"), but if coming up with that > >>>> guidance takes more than about a week, I don't see a lot of > >>> reason to > >>>> hold up on "don't go there" > >>>> while we explore alternatives. > >>>> - INFO and DTMF > >>>> - XML payloads > >>>> - But people really need is guidance on when to use INFO, when to > >>>> use events, and when to use something entirely different. > >>>> - identification of purpose of info (Content-Type? - impacted by > >>>> multipart/mixed) > >>>> - any framework for control of usages (IANA registration? - RFC > >>>> 3427 update) > >>>> > >>>> Would anybody out there like to have a go at drafting an > >>> abstract for a > >>>> potential WG deliverable (and also identifying level - Info, BCP, > >>>> standards track) and submitting it to the list for > >>> discussion. Remember > >>>> an abstract needs to: > >>>> > >>>> > >>> -------------------------------------------------------------- > >>> ---------- > >>>> ------- > >>>> Every RFC must have an Abstract section following the > >>> Copyright notice. > >>>> An Abstract will typically be 5-10 lines. An Abstract of > >>> more than 20 > >>>> lines is generally not acceptable. > >>>> > >>>> The Abstract section should provide a concise and > >>> comprehensive overview > >>>> of the purpose and contents of the entire document, to give a > >>>> technically knowledgeable reader a general overview of the > >>> function of > >>>> the document. In addition to its function in the RFC itself, the > >>>> Abstract section text will appear in publication > >>> announcements and in > >>>> the online index of RFCs. > >>>> > >>>> Composing a useful Abstract generally requires thought and > >>> care. Usually > >>>> an Abstract should begin with a phrase like "This memo > >> ..." or "This > >>>> document ...". A satisfactory abstract can often be > >>> constructed in part > >>>> from material within the Introduction section, but a good > >>> abstract will > >>>> be shorter, less detailed, and perhaps broader in scope than the > >>>> Introduction. Simply copying and pasting the first few > >>> paragraphs of the > >>>> Introduction is tempting, but it may result in an Abstract > >>> that is both > >>>> incomplete and redundant. Note also that an Abstract is not > >>> a substitute > >>>> for an Introduction; the RFC should be self-contained as if > >>> there were > >>>> no Abstract section. > >>>> > >>>> An Abstract should be complete in itself; it should not contain > >>>> citations unless they are completely defined within the Abstract. > >>>> Abbreviations appearing in the Abstract should generally be > >>> expanded in > >>>> parentheses. There is a small set of reasonable exceptions > >>> to this rule > >>>> (see guidelines on abbreviations, above.) > >>>> > >>> -------------------------------------------------------------- > >>> ---------- > >>>> ------ > >>>> > >>>> And as such should give a clear idea of whether there is > >> anything we > >>>> should charter here or not. > >>>> > >>>> Regards > >>>> > >>>> Keith > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>> This list is for NEW development of the core SIP Protocol > >>>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>>> Use sipping@ietf.org for new developments on the > >> application of sip > >>> > >>> Notice: This email message, together with any attachments, > >>> may contain information of BEA Systems, Inc., its > >>> subsidiaries and affiliated entities, that may be > >>> confidential, proprietary, copyrighted and/or legally > >>> privileged, and is intended solely for the use of the > >>> individual or entity named in this message. If you are not > >>> the intended recipient, and have received this message in > >>> error, please immediately return this by email and then delete it. > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of = sip > >>> > >> Notice: This email message, together with any attachments, > >> may contain information of BEA Systems, Inc., its > >> subsidiaries and affiliated entities, that may be > >> confidential, proprietary, copyrighted and/or legally > >> privileged, and is intended solely for the use of the > >> individual or entity named in this message. If you are not > >> the intended recipient, and have received this message in > >> error, please immediately return this by email and then delete it. > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 12:34:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gfG-00019b-IN; Tue, 19 Jun 2007 12:34:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0gfF-00019M-9j for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gfF-00019E-0F for sip@ietf.org; Tue, 19 Jun 2007 12:34:45 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gfD-0003Kc-M6 for sip@ietf.org; Tue, 19 Jun 2007 12:34:44 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5JGYgXj010755; Tue, 19 Jun 2007 11:34:42 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5JGYfa28502; Tue, 19 Jun 2007 11:34:41 -0500 (CDT) Message-ID: <467805A1.5090406@alcatel-lucent.com> Date: Tue, 19 Jun 2007 11:34:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Francois Audet wrote: > Agreed. > > Basically, say the "CONNECT" ended up in 3 different directions after > a 3XX with 3 contacts. The UAC would set up the end-to-end TLS > connections from the UAC to the 3 contacts. > > Then the INVITEs have no intermediaries, so they can't fork. OK; returning a 3xx seems to be preferred. Then, so that we can update the next revision appropriately, here is some rough text: A proxy that accesses a location service to route a CONNECT request and discovers more than one contact bound to that AoR MUST format a 3xx-class response with the contacts discovered from the location service. This response is subsequently sent upstream. A proxy that receives a 3xx-class response as a result of proxying a CONNECT request downstream MUST NOT recurse on the receipt of the 3xx-class response. Instead, it MUST send the response upstream. When a user agent receives a 3xx-class response from its downstream server with multiple Contact headers, it MAY decide to fork in parallel or in serial depending on its software capabilities and configuration policies. Alternatively, it MAY analyze the received Contact headers and choose to send it to a particular destination that it suspects would stand the best chance of eliciting a successful response. OK? - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 12:37:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ghj-0004zd-TE; Tue, 19 Jun 2007 12:37:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0ghi-0004zX-7A for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 12:37:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ghh-0004zP-Tv for sip@ietf.org; Tue, 19 Jun 2007 12:37:17 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ghe-0005Gf-H7 for sip@ietf.org; Tue, 19 Jun 2007 12:37:17 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JGbBm23368; Tue, 19 Jun 2007 16:37:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Tue, 19 Jun 2007 11:37:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3516@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256705980474@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AcexOqGN4DEnzx0tEdy0uwAWy4mm/wASFW7gABK58qQABYFnAAAc2ORtAAByriAADUiNAA== References: <7374777208BDC7449D5620EF9423256705980474@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg (JO/LMF)" , "Eric Burger" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm not sure what is the point of this INFO discussion. We won't stop people for using INFO for what they have been using it for quite a few years now, and I don't think it would be a proper use of our = time to attempt to do so. Especially after we defined RFCs explaining that INFO = was=20 useful for PSTN tunnelling. However, what we can do is ensure that we do not define any new RFCs = that use it. That's easy enough to do. We could also attempt to discourage other Standards Bodies or Forum from = using INFO as the kitchen sink (e.g., ECMA TR/87). In the absence of any = guidance from us, the natural thing for these organizations to do is to use INFO because = it's so simple.=20 So, I'd suggest a Standards Track RFC that updates 2976 and makes it = explicit that INFO is strictly for PSTN tunnelling (refer to=20 I think for this purpose, something that caps the use of INFO (from a=20 standards perspective) to the usages documented in IETF so far (i.e., = PSTN protocol tunneling as per RFC 3204). We should also describe the main issues with = it (i.e., no negotiation, and overloading of signalling channel), and points to = alternatives: 1 - SUBSCRIBE/NOTIFY 2 - A separate protocol (possibly bootstrapped through SIP, =E0 la = Content indirection 3 - MSRP 4 - etc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 15:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jeI-00060v-Ml; Tue, 19 Jun 2007 15:45:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0jeH-0005zA-0h for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jeG-0005z2-NX for sip@ietf.org; Tue, 19 Jun 2007 15:45:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jeF-00065N-Cb for sip@ietf.org; Tue, 19 Jun 2007 15:45:56 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJW0024FEW7W1@siemenscomms.co.uk> for sip@ietf.org; Tue, 19 Jun 2007 20:45:43 +0100 (BST) Date: Tue, 19 Jun 2007 20:45:53 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 In-reply-to: <467805A1.5090406@alcatel-lucent.com> To: "Vijay K. Gurbani" , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj83MZsxqkL0yQICEoUk0YPuD3gAGi//w Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: IETF SIP List , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Vijay, This deals with straightforward forking scenarios. What about a proxy that is scripted to fork in parallel to two destinations, and then, if they both fail to answer, fork to a third destination? Or a proxy that is scripted to forward to one destination, and then, if it fails to answer after a certain time, fork to a second location without cancelling the request at the first destination? John > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: 19 June 2007 17:35 > To: Francois Audet > Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > Francois Audet wrote: > > Agreed. > > > > Basically, say the "CONNECT" ended up in 3 different > directions after > > a 3XX with 3 contacts. The UAC would set up the end-to-end TLS > > connections from the UAC to the 3 contacts. > > > > Then the INVITEs have no intermediaries, so they can't fork. > > OK; returning a 3xx seems to be preferred. Then, so that we can > update the next revision appropriately, here is some rough text: > > A proxy that accesses a location service to route a CONNECT > request and discovers more than one contact bound to that > AoR MUST format a 3xx-class response with the contacts discovered > from the location service. This response is subsequently > sent upstream. > > A proxy that receives a 3xx-class response as a result of > proxying a CONNECT request downstream MUST NOT recurse on the > receipt of the 3xx-class response. Instead, it MUST send the > response upstream. > > When a user agent receives a 3xx-class response from its > downstream server with multiple Contact headers, it MAY decide > to fork in parallel or in serial depending on its software > capabilities and configuration policies. Alternatively, it > MAY analyze the received Contact headers and choose to send it > to a particular destination that it suspects would stand the > best chance of eliciting a successful response. > > OK? > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 15:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0joe-0005Ke-Ps; Tue, 19 Jun 2007 15:56:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0jod-0005Jf-Kq for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:56:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jod-0005JL-AS for sip@ietf.org; Tue, 19 Jun 2007 15:56:39 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0joc-0000Mt-Fp for sip@ietf.org; Tue, 19 Jun 2007 15:56:39 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E573B204A7; Tue, 19 Jun 2007 21:56:37 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-d9-467834f5dc24 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BBAE020070; Tue, 19 Jun 2007 21:56:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 21:56:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 21:56:36 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> In-Reply-To: <467805A1.5090406@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj8V3cvA+zHOFT7uZ3ZV93PZDAwAGASGA References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> From: "Christer Holmberg (JO/LMF)" To: "Vijay K. Gurbani" , "Francois Audet" X-OriginalArrivalTime: 19 Jun 2007 19:56:37.0086 (UTC) FILETIME=[F1E5A7E0:01C7B2AB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, A small comment. I don't think we in the draft should say that the UA forks. Because, I = don't think the UA behavior is different from when it receives a 3xx = response for e.g. an initial INVITE, is it? It uses the contact in the = response to initiates new initial request. We don't call that forking, = do we? Regards, Christer > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 > Sent: 19. kes=E4kuuta 2007 19:35 > To: Francois Audet > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 >=20 > Francois Audet wrote: > > Agreed. > >=20 > > Basically, say the "CONNECT" ended up in 3 different=20 > directions after=20 > > a 3XX with 3 contacts. The UAC would set up the end-to-end TLS=20 > > connections from the UAC to the 3 contacts. > >=20 > > Then the INVITEs have no intermediaries, so they can't fork. >=20 > OK; returning a 3xx seems to be preferred. Then, so that we=20 > can update the next revision appropriately, here is some rough text: >=20 > A proxy that accesses a location service to route a CONNECT > request and discovers more than one contact bound to that > AoR MUST format a 3xx-class response with the contacts discovered > from the location service. This response is subsequently > sent upstream. >=20 > A proxy that receives a 3xx-class response as a result of > proxying a CONNECT request downstream MUST NOT recurse on the > receipt of the 3xx-class response. Instead, it MUST send the > response upstream. >=20 > When a user agent receives a 3xx-class response from its > downstream server with multiple Contact headers, it MAY decide > to fork in parallel or in serial depending on its software > capabilities and configuration policies. Alternatively, it > MAY analyze the received Contact headers and choose to send it > to a particular destination that it suspects would stand the > best chance of eliciting a successful response. >=20 > OK? >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 16:10:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k1f-0007Sd-SH; Tue, 19 Jun 2007 16:10:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0k1e-0007SB-4w for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:10:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0k1d-0007S2-Rf for sip@ietf.org; Tue, 19 Jun 2007 16:10:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0k1c-0003PC-G6 for sip@ietf.org; Tue, 19 Jun 2007 16:10:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JK9xr19848; Tue, 19 Jun 2007 20:09:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 15:09:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE39C0@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj8V3cvA+zHOFT7uZ3ZV93PZDAwAGASGAAAFy5LA= References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg (JO/LMF)" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I call it UA forking (as opposed to proxy forking). I'm ok with calling it something else.=20 I have a funny feeling that if we had made the distinction=20 clearer way back when we were discussing the merits of forking, we would have had a different outcome. > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 19, 2007 12:57 > To: Vijay K. Gurbani; Audet, Francois (SC100:3055) > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 >=20 >=20 > Hi, >=20 > A small comment. >=20 > I don't think we in the draft should say that the UA forks.=20 > Because, I don't think the UA behavior is different from when=20 > it receives a 3xx response for e.g. an initial INVITE, is it?=20 > It uses the contact in the response to initiates new initial=20 > request. We don't call that forking, do we? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > Sent: 19. kes=E4kuuta 2007 19:35 > > To: Francois Audet > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > >=20 > > Francois Audet wrote: > > > Agreed. > > >=20 > > > Basically, say the "CONNECT" ended up in 3 different > > directions after > > > a 3XX with 3 contacts. The UAC would set up the end-to-end TLS=20 > > > connections from the UAC to the 3 contacts. > > >=20 > > > Then the INVITEs have no intermediaries, so they can't fork. > >=20 > > OK; returning a 3xx seems to be preferred. Then, so that we can=20 > > update the next revision appropriately, here is some rough text: > >=20 > > A proxy that accesses a location service to route a CONNECT > > request and discovers more than one contact bound to that > > AoR MUST format a 3xx-class response with the contacts discovered > > from the location service. This response is subsequently > > sent upstream. > >=20 > > A proxy that receives a 3xx-class response as a result of > > proxying a CONNECT request downstream MUST NOT recurse on the > > receipt of the 3xx-class response. Instead, it MUST send the > > response upstream. > >=20 > > When a user agent receives a 3xx-class response from its > > downstream server with multiple Contact headers, it MAY decide > > to fork in parallel or in serial depending on its software > > capabilities and configuration policies. Alternatively, it > > MAY analyze the received Contact headers and choose to send it > > to a particular destination that it suspects would stand the > > best chance of eliciting a successful response. > >=20 > > OK? > >=20 > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > WWW: http://www.alcatel-lucent.com/bell-labs > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 16:42:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kWV-0000R4-H7; Tue, 19 Jun 2007 16:41:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0kWU-0000Qt-9C for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kWT-0000Ql-Vt for sip@ietf.org; Tue, 19 Jun 2007 16:41:57 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kWS-0004Nf-Mp for sip@ietf.org; Tue, 19 Jun 2007 16:41:57 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5JKftYW007737; Tue, 19 Jun 2007 15:41:55 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5JKfqa02949; Tue, 19 Jun 2007 15:41:52 -0500 (CDT) Message-ID: <46783F90.4080405@alcatel-lucent.com> Date: Tue, 19 Jun 2007 15:41:52 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: IETF SIP List , Francois Audet , Paul Kyzivat , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Vijay, > > This deals with straightforward forking scenarios. OK; good. > What about a proxy that is scripted to fork in parallel to two > destinations, and then, if they both fail to answer, fork to a third > destination? Or a proxy that is scripted to forward to one > destination, and then, if it fails to answer after a certain time, > fork to a second location without cancelling the request at the first > destination? Presumably, if the proxy understands the "Proxy-Require: sipsec" option tag, it will follow the normative behavior of returning the destinations in a 3xx instead of launching into the fork dance. If it is a legacy proxy, it should reject the CONNECT request on encountering a "Proxy-Require: sipsec" option tag. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 16:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kdx-0004jB-R9; Tue, 19 Jun 2007 16:49:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0kdx-0004hV-4o for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kdw-0004hN-RP for sip@ietf.org; Tue, 19 Jun 2007 16:49:40 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kdm-0006Km-Nq for sip@ietf.org; Tue, 19 Jun 2007 16:49:40 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 20A7C20164; Tue, 19 Jun 2007 22:49:30 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-06-4678415aa3af Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED4F4200D3; Tue, 19 Jun 2007 22:49:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 22:49:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 22:49:27 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705A3D760@esealmw113.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF10EE39C0@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj8V3cvA+zHOFT7uZ3ZV93PZDAwAGASGAAAFy5LAAATu3QA== References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com><46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com><4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com><467805A1.5090406@alcatel-lucent.com><7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF10EE39C0@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg (JO/LMF)" To: "Francois Audet" , "Vijay K. Gurbani" X-OriginalArrivalTime: 19 Jun 2007 20:49:29.0830 (UTC) FILETIME=[54FFF860:01C7B2B3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >I call it UA forking (as opposed to proxy forking). I don't think 3261 calls it UA forking. When triggering requests based on a 3xx response, I think 3261 talks = about "recursion". Regards, Christer >I'm ok with calling it something else.=20 >=20 >I have a funny feeling that if we had made the distinction=20 >clearer way back when we were discussing the merits of=20 >forking, we would have had a different outcome. >=20 > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 19, 2007 12:57 > > To: Vijay K. Gurbani; Audet, Francois (SC100:3055) > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > >=20 > >=20 > > Hi, > >=20 > > A small comment. > >=20 > > I don't think we in the draft should say that the UA forks.=20 > > Because, I don't think the UA behavior is different from when it=20 > > receives a 3xx response for e.g. an initial INVITE, is it? > > It uses the contact in the response to initiates new=20 > initial request.=20 > > We don't call that forking, do we? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > > Sent: 19. kes=E4kuuta 2007 19:35 > > > To: Francois Audet > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > >=20 > > > Francois Audet wrote: > > > > Agreed. > > > >=20 > > > > Basically, say the "CONNECT" ended up in 3 different > > > directions after > > > > a 3XX with 3 contacts. The UAC would set up the end-to-end TLS=20 > > > > connections from the UAC to the 3 contacts. > > > >=20 > > > > Then the INVITEs have no intermediaries, so they can't fork. > > >=20 > > > OK; returning a 3xx seems to be preferred. Then, so that we can=20 > > > update the next revision appropriately, here is some rough text: > > >=20 > > > A proxy that accesses a location service to route a CONNECT > > > request and discovers more than one contact bound to that > > > AoR MUST format a 3xx-class response with the contacts=20 > discovered > > > from the location service. This response is subsequently > > > sent upstream. > > >=20 > > > A proxy that receives a 3xx-class response as a result of > > > proxying a CONNECT request downstream MUST NOT recurse on the > > > receipt of the 3xx-class response. Instead, it MUST send the > > > response upstream. > > >=20 > > > When a user agent receives a 3xx-class response from its > > > downstream server with multiple Contact headers, it MAY decide > > > to fork in parallel or in serial depending on its software > > > capabilities and configuration policies. Alternatively, it > > > MAY analyze the received Contact headers and choose to send it > > > to a particular destination that it suspects would stand the > > > best chance of eliciting a successful response. > > >=20 > > > OK? > > >=20 > > > - vijay > > > -- > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > > WWW: http://www.alcatel-lucent.com/bell-labs > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 16:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kfM-0005Pv-7f; Tue, 19 Jun 2007 16:51:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0kfJ-0005Pc-Mo for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:51:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kfJ-0005PU-Cv for sip@ietf.org; Tue, 19 Jun 2007 16:51:05 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kfI-0006gY-19 for sip@ietf.org; Tue, 19 Jun 2007 16:51:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JKp0m13108; Tue, 19 Jun 2007 20:51:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 15:50:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3ACE@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256705A3D760@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj8V3cvA+zHOFT7uZ3ZV93PZDAwAGASGAAAFy5LAAATu3QAAAOoUQ References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com><46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com><4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com><467805A1.5090406@alcatel-lucent.com><7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF10EE39C0@zrc2hxm0.corp.nortel.com> <7374777208BDC7449D5620EF9423256705A3D760@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg (JO/LMF)" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org We can call it UA recursion versus proxy forking. It's fine with me.=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 19, 2007 13:49 > To: Audet, Francois (SC100:3055); Vijay K. Gurbani > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 >=20 >=20 > Hi,=20 >=20 > >I call it UA forking (as opposed to proxy forking). >=20 > I don't think 3261 calls it UA forking. >=20 > When triggering requests based on a 3xx response, I think=20 > 3261 talks about "recursion". >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > >I'm ok with calling it something else.=20 > >=20 > >I have a funny feeling that if we had made the distinction=20 > clearer way=20 > >back when we were discussing the merits of forking, we would=20 > have had a=20 > >different outcome. > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, June 19, 2007 12:57 > > > To: Vijay K. Gurbani; Audet, Francois (SC100:3055) > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > >=20 > > >=20 > > > Hi, > > >=20 > > > A small comment. > > >=20 > > > I don't think we in the draft should say that the UA forks.=20 > > > Because, I don't think the UA behavior is different from when it=20 > > > receives a 3xx response for e.g. an initial INVITE, is it? > > > It uses the contact in the response to initiates new > > initial request.=20 > > > We don't call that forking, do we? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > > > Sent: 19. kes=E4kuuta 2007 19:35 > > > > To: Francois Audet > > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > >=20 > > > > Francois Audet wrote: > > > > > Agreed. > > > > >=20 > > > > > Basically, say the "CONNECT" ended up in 3 different > > > > directions after > > > > > a 3XX with 3 contacts. The UAC would set up the=20 > end-to-end TLS=20 > > > > > connections from the UAC to the 3 contacts. > > > > >=20 > > > > > Then the INVITEs have no intermediaries, so they can't fork. > > > >=20 > > > > OK; returning a 3xx seems to be preferred. Then, so=20 > that we can=20 > > > > update the next revision appropriately, here is some rough text: > > > >=20 > > > > A proxy that accesses a location service to route a CONNECT > > > > request and discovers more than one contact bound to that > > > > AoR MUST format a 3xx-class response with the contacts > > discovered > > > > from the location service. This response is subsequently > > > > sent upstream. > > > >=20 > > > > A proxy that receives a 3xx-class response as a result of > > > > proxying a CONNECT request downstream MUST NOT recurse on the > > > > receipt of the 3xx-class response. Instead, it MUST send the > > > > response upstream. > > > >=20 > > > > When a user agent receives a 3xx-class response from its > > > > downstream server with multiple Contact headers, it=20 > MAY decide > > > > to fork in parallel or in serial depending on its software > > > > capabilities and configuration policies. Alternatively, it > > > > MAY analyze the received Contact headers and choose=20 > to send it > > > > to a particular destination that it suspects would stand the > > > > best chance of eliciting a successful response. > > > >=20 > > > > OK? > > > >=20 > > > > - vijay > > > > -- > > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > > > WWW: http://www.alcatel-lucent.com/bell-labs > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 16:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kgJ-0006Fq-Jb; Tue, 19 Jun 2007 16:52:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0kgI-0006F0-7Y for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kgH-0006Eo-Tu for sip@ietf.org; Tue, 19 Jun 2007 16:52:05 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kgG-0006uv-Dy for sip@ietf.org; Tue, 19 Jun 2007 16:52:05 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5JKq0r24856; Tue, 19 Jun 2007 20:52:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 15:51:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3AD3@zrc2hxm0.corp.nortel.com> In-Reply-To: <7374777208BDC7449D5620EF9423256705A3D760@esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceyj8V3cvA+zHOFT7uZ3ZV93PZDAwAGASGAAAFy5LAAATu3QAAAQI8Q References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com><46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com><4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com><467805A1.5090406@alcatel-lucent.com><7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF10EE39C0@zrc2hxm0.corp.nortel.com> <7374777208BDC7449D5620EF9423256705A3D760@esealmw113.eemea.ericsson.se> From: "Francois Audet" To: "Christer Holmberg (JO/LMF)" , "Vijay K. Gurbani" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: IETF SIP List , Paul Kyzivat , "Elwell, John" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The value (from an end-user perspective) is "Simultaneous or Parallel = Ringing". At the technical level it is implementable either using proxy forking, = or with UA recursion.=20 > -----Original Message----- > From: Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 19, 2007 13:49 > To: Audet, Francois (SC100:3055); Vijay K. Gurbani > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 >=20 >=20 > Hi,=20 >=20 > >I call it UA forking (as opposed to proxy forking). >=20 > I don't think 3261 calls it UA forking. >=20 > When triggering requests based on a 3xx response, I think=20 > 3261 talks about "recursion". >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 > >I'm ok with calling it something else.=20 > >=20 > >I have a funny feeling that if we had made the distinction=20 > clearer way=20 > >back when we were discussing the merits of forking, we would=20 > have had a=20 > >different outcome. > >=20 > > > -----Original Message----- > > > From: Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, June 19, 2007 12:57 > > > To: Vijay K. Gurbani; Audet, Francois (SC100:3055) > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > >=20 > > >=20 > > > Hi, > > >=20 > > > A small comment. > > >=20 > > > I don't think we in the draft should say that the UA forks.=20 > > > Because, I don't think the UA behavior is different from when it=20 > > > receives a 3xx response for e.g. an initial INVITE, is it? > > > It uses the contact in the response to initiates new > > initial request.=20 > > > We don't call that forking, do we? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > > > Sent: 19. kes=E4kuuta 2007 19:35 > > > > To: Francois Audet > > > > Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis > > > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > >=20 > > > > Francois Audet wrote: > > > > > Agreed. > > > > >=20 > > > > > Basically, say the "CONNECT" ended up in 3 different > > > > directions after > > > > > a 3XX with 3 contacts. The UAC would set up the=20 > end-to-end TLS=20 > > > > > connections from the UAC to the 3 contacts. > > > > >=20 > > > > > Then the INVITEs have no intermediaries, so they can't fork. > > > >=20 > > > > OK; returning a 3xx seems to be preferred. Then, so=20 > that we can=20 > > > > update the next revision appropriately, here is some rough text: > > > >=20 > > > > A proxy that accesses a location service to route a CONNECT > > > > request and discovers more than one contact bound to that > > > > AoR MUST format a 3xx-class response with the contacts > > discovered > > > > from the location service. This response is subsequently > > > > sent upstream. > > > >=20 > > > > A proxy that receives a 3xx-class response as a result of > > > > proxying a CONNECT request downstream MUST NOT recurse on the > > > > receipt of the 3xx-class response. Instead, it MUST send the > > > > response upstream. > > > >=20 > > > > When a user agent receives a 3xx-class response from its > > > > downstream server with multiple Contact headers, it=20 > MAY decide > > > > to fork in parallel or in serial depending on its software > > > > capabilities and configuration policies. Alternatively, it > > > > MAY analyze the received Contact headers and choose=20 > to send it > > > > to a particular destination that it suspects would stand the > > > > best chance of eliciting a successful response. > > > >=20 > > > > OK? > > > >=20 > > > > - vijay > > > > -- > > > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > > > WWW: http://www.alcatel-lucent.com/bell-labs > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > > > sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > > > sipping@ietf.org for new developments on the application of sip > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 18:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mNO-0007BP-Fp; Tue, 19 Jun 2007 18:40:42 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0mNM-00076e-Ld for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mNM-00076W-Bu for sip@ietf.org; Tue, 19 Jun 2007 18:40:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mNK-0002jP-SJ for sip@ietf.org; Tue, 19 Jun 2007 18:40:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 19 Jun 2007 15:40:38 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOP3d0arR7O6h2dsb2JhbACIS4ZMAQEBCA4snSg X-IronPort-AV: i="4.16,439,1175497200"; d="scan'208"; a="380600212:sNHT34157596" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JMeciB027152; Tue, 19 Jun 2007 15:40:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5JMeTtV018123; Tue, 19 Jun 2007 22:40:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 18:40:28 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 18:40:28 -0400 Message-ID: <46785B5B.2090509@cisco.com> Date: Tue, 19 Jun 2007 18:40:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF9423256705A3D734@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jun 2007 22:40:28.0368 (UTC) FILETIME=[D5CC3D00:01C7B2C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3142; t=1182292838; x=1183156838; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-gurbani-sip-sipsec-01 |Sender:=20; bh=AbmsEsz60dijH2XcaAaHrRgVbarAqhnufvdAcsLETSc=; b=xWRHe7jrP7HmITWew976+6/bhpdZIQ9tTqcvN9YnnZdrG6XRW2CHlj1qyMQ1mph30yFDk93/ 2KgW39IMMQ7DYIJiG5w/tr8piiYwXqWJMZxbQwGew663mv8f0WOWT9H6; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List , Francois Audet , Dean Willis , "Elwell, John" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Christer Holmberg (JO/LMF) wrote: > Hi, > > A small comment. > > I don't think we in the draft should say that the UA forks. Because, I don't think the UA behavior is different from when it receives a 3xx response for e.g. an initial INVITE, is it? It uses the contact in the response to initiates new initial request. We don't call that forking, do we? whatever you call it, there is still a difference between trying things serially and trying them in parallel. If the UA gets a 3xx with one contact and recurses on it then you have serial forking. If the UA gets a 3xx with multiple contacts and tries them one by one you still have serial forking. If the UA gets a 3xx with multiple contacts and tries them all at once then you have parallel forking. Paul > Regards, > > Christer > > > >> -----Original Message----- >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >> Sent: 19. kesäkuuta 2007 19:35 >> To: Francois Audet >> Cc: IETF SIP List; Paul Kyzivat; Elwell,John; Dean Willis >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 >> >> Francois Audet wrote: >>> Agreed. >>> >>> Basically, say the "CONNECT" ended up in 3 different >> directions after >>> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS >>> connections from the UAC to the 3 contacts. >>> >>> Then the INVITEs have no intermediaries, so they can't fork. >> OK; returning a 3xx seems to be preferred. Then, so that we >> can update the next revision appropriately, here is some rough text: >> >> A proxy that accesses a location service to route a CONNECT >> request and discovers more than one contact bound to that >> AoR MUST format a 3xx-class response with the contacts discovered >> from the location service. This response is subsequently >> sent upstream. >> >> A proxy that receives a 3xx-class response as a result of >> proxying a CONNECT request downstream MUST NOT recurse on the >> receipt of the 3xx-class response. Instead, it MUST send the >> response upstream. >> >> When a user agent receives a 3xx-class response from its >> downstream server with multiple Contact headers, it MAY decide >> to fork in parallel or in serial depending on its software >> capabilities and configuration policies. Alternatively, it >> MAY analyze the received Contact headers and choose to send it >> to a particular destination that it suspects would stand the >> best chance of eliciting a successful response. >> >> OK? >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 18:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mYS-0007Qz-EV; Tue, 19 Jun 2007 18:52:08 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0mYR-0007Qu-Gq for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:52:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mYR-0007Pa-6M for sip@ietf.org; Tue, 19 Jun 2007 18:52:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mYQ-0004va-NY for sip@ietf.org; Tue, 19 Jun 2007 18:52:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2007 15:52:01 -0700 X-IronPort-AV: i="4.16,440,1175497200"; d="scan'208"; a="168340254:sNHT1199997162" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5JMq1Ua000412; Tue, 19 Jun 2007 15:52:01 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JMpu20028003; Tue, 19 Jun 2007 22:52:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 18:51:56 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 18:51:55 -0400 Message-ID: <46785E08.1030203@cisco.com> Date: Tue, 19 Jun 2007 18:51:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 22:51:55.0739 (UTC) FILETIME=[6F80BAB0:01C7B2C4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3510; t=1182293521; x=1183157521; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20draft-gurbani-sip-sipsec-01 |Sender:=20; bh=CrtBB1KjEoqein5HzVFGmr9IlaFZ5ZnNxMcix1SLRtc=; b=JpDRyUbIDGNbxazT/lTl8/G6FLaMoGrxE2q6iW2JbwD6zsgaAn0JjJ6YeGyt/zd6Es0BxKtm K7eR2ynFfpD8YF0mh9ykRAStDfuzwcmXnwl8zwxdb4cUPo2jVrCAi9Vs; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: IETF SIP List , Francois Audet , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Elwell, John wrote: > Vijay, > > This deals with straightforward forking scenarios. What about a proxy > that is scripted to fork in parallel to two destinations, and then, if > they both fail to answer, fork to a third destination? Or a proxy that > is scripted to forward to one destination, and then, if it fails to > answer after a certain time, fork to a second location without > cancelling the request at the first destination? Some of these cases can be handled by attaching q-values to the contacts in the 3xx, if the UA cooperates by doing the ones with equal q-value in parallel and the ones with different q-values in descending q-value order. But it doesn't deal with more complex policy. And of course if this is done by the callee's home proxy then it can be certain the policy is followed. If it is deferred to the caller then you can't be sure. Of course this is to some extent a battle over who's policy should be followed, and there is no single right answer here. But its probably safe to assume that many callee's won't want to give up control over this. An alternative I suggested earlier, that nobody commented on, is to start out with a regular INVITE, which can potentially fork. After a dialog is established, do a CONNECT/Replaces to establish a secure session to the target. This could be done during an early dialog, or after the final dialog is established. This could be triggered by presence of "Supported:sipsec" in the response. Paul > John > >> -----Original Message----- >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] >> Sent: 19 June 2007 17:35 >> To: Francois Audet >> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 >> >> Francois Audet wrote: >>> Agreed. >>> >>> Basically, say the "CONNECT" ended up in 3 different >> directions after >>> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS >>> connections from the UAC to the 3 contacts. >>> >>> Then the INVITEs have no intermediaries, so they can't fork. >> OK; returning a 3xx seems to be preferred. Then, so that we can >> update the next revision appropriately, here is some rough text: >> >> A proxy that accesses a location service to route a CONNECT >> request and discovers more than one contact bound to that >> AoR MUST format a 3xx-class response with the contacts discovered >> from the location service. This response is subsequently >> sent upstream. >> >> A proxy that receives a 3xx-class response as a result of >> proxying a CONNECT request downstream MUST NOT recurse on the >> receipt of the 3xx-class response. Instead, it MUST send the >> response upstream. >> >> When a user agent receives a 3xx-class response from its >> downstream server with multiple Contact headers, it MAY decide >> to fork in parallel or in serial depending on its software >> capabilities and configuration policies. Alternatively, it >> MAY analyze the received Contact headers and choose to send it >> to a particular destination that it suspects would stand the >> best chance of eliciting a successful response. >> >> OK? >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >> WWW: http://www.alcatel-lucent.com/bell-labs >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 18:59:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mfS-0006Qx-Cu; Tue, 19 Jun 2007 18:59:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0mfQ-0006Qr-UG for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 18:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0mfQ-0006Qj-Kf for sip@ietf.org; Tue, 19 Jun 2007 18:59:20 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0mfO-0005x2-A8 for sip@ietf.org; Tue, 19 Jun 2007 18:59:20 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l5JMvrv25841; Tue, 19 Jun 2007 22:57:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Tue, 19 Jun 2007 17:59:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10EE3CFA@zrc2hxm0.corp.nortel.com> In-Reply-To: <46785E08.1030203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceyxHxs1Kmx5P/WRoGSZU2TXmO3/wAANFuA References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> <46785E08.1030203@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Elwell, John" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah, we tought about that. The problem is that the INVITE is loaded with too much information that would then leak. The idea of the CONNECT is that it would have the bare minimum to route. Then the full blown end-to-end secure INVITE (with the SDP) could be exchanged.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, June 19, 2007 15:52 > To: Elwell, John > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF SIP=20 > List; Dean Willis > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 >=20 >=20 >=20 > Elwell, John wrote: > > Vijay, > >=20 > > This deals with straightforward forking scenarios. What=20 > about a proxy=20 > > that is scripted to fork in parallel to two destinations,=20 > and then, if=20 > > they both fail to answer, fork to a third destination? Or a=20 > proxy that=20 > > is scripted to forward to one destination, and then, if it fails to=20 > > answer after a certain time, fork to a second location without=20 > > cancelling the request at the first destination? >=20 > Some of these cases can be handled by attaching q-values to=20 > the contacts in the 3xx, if the UA cooperates by doing the=20 > ones with equal q-value in parallel and the ones with=20 > different q-values in descending q-value order. >=20 > But it doesn't deal with more complex policy. And of course=20 > if this is done by the callee's home proxy then it can be=20 > certain the policy is followed. If it is deferred to the=20 > caller then you can't be sure. >=20 > Of course this is to some extent a battle over who's policy=20 > should be followed, and there is no single right answer here.=20 > But its probably safe to assume that many callee's won't want=20 > to give up control over this. >=20 > An alternative I suggested earlier, that nobody commented on,=20 > is to start out with a regular INVITE, which can potentially=20 > fork. After a dialog is established, do a CONNECT/Replaces to=20 > establish a secure session to the target. This could be done=20 > during an early dialog, or after the final dialog is=20 > established. This could be triggered by presence of=20 > "Supported:sipsec" in the response. >=20 > Paul >=20 > > John > >=20 > >> -----Original Message----- > >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > >> Sent: 19 June 2007 17:35 > >> To: Francois Audet > >> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John > >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > >> > >> Francois Audet wrote: > >>> Agreed. > >>> > >>> Basically, say the "CONNECT" ended up in 3 different > >> directions after > >>> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS=20 > >>> connections from the UAC to the 3 contacts. > >>> > >>> Then the INVITEs have no intermediaries, so they can't fork. > >> OK; returning a 3xx seems to be preferred. Then, so that we can=20 > >> update the next revision appropriately, here is some rough text: > >> > >> A proxy that accesses a location service to route a CONNECT > >> request and discovers more than one contact bound to that > >> AoR MUST format a 3xx-class response with the contacts=20 > discovered > >> from the location service. This response is subsequently > >> sent upstream. > >> > >> A proxy that receives a 3xx-class response as a result of > >> proxying a CONNECT request downstream MUST NOT recurse on the > >> receipt of the 3xx-class response. Instead, it MUST send the > >> response upstream. > >> > >> When a user agent receives a 3xx-class response from its > >> downstream server with multiple Contact headers, it MAY decide > >> to fork in parallel or in serial depending on its software > >> capabilities and configuration policies. Alternatively, it > >> MAY analyze the received Contact headers and choose to send it > >> to a particular destination that it suspects would stand the > >> best chance of eliciting a successful response. > >> > >> OK? > >> > >> - vijay > >> -- > >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > >> WWW: http://www.alcatel-lucent.com/bell-labs > >> > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 19:34:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nDP-0005jB-1X; Tue, 19 Jun 2007 19:34:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0nDN-0005j5-EB for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 19:34:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nDN-0005iJ-4O for sip@ietf.org; Tue, 19 Jun 2007 19:34:25 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nDL-0003VP-Qy for sip@ietf.org; Tue, 19 Jun 2007 19:34:25 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 19:34:24 -0400 X-IronPort-AV: i="4.16,440,1175486400"; d="scan'208"; a="124076859:sNHT53319462" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JNYNbU020638; Tue, 19 Jun 2007 19:34:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JNYEBi024842; Tue, 19 Jun 2007 23:34:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 19:34:18 -0400 Received: from [63.118.137.64] ([10.82.240.17]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 19:34:18 -0400 Message-ID: <467867F9.2030501@cisco.com> Date: Tue, 19 Jun 2007 19:34:17 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Sip] INFO usage (or not) References: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567056C1E21@esealmw113.eemea.ericsson.se> In-Reply-To: <7374777208BDC7449D5620EF94232567056C1E21@esealmw113.eemea.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 23:34:18.0695 (UTC) FILETIME=[5B390570:01C7B2CA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2829; t=1182296063; x=1183160063; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20INFO=20usage=20(or=20not) |Sender:=20 |To:=20=22Christer=20Holmberg=20(JO/LMF)=22=20; bh=ivxkRMDM7uKnoqqiE17LyvO04BCckd8sg6qipbdc92c=; b=FQIK6jo6vusUNw7ETyxPJNXkoH2RipC/rZx6YOcNq+mq1L8cvIh3lxC6RckDPGJTUyVHEped c5swbmWXnne7tM+Wx2dCPzkIeacMJsBnYlcxZ1YX5axx4XnkL6a1DV/V; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org inline. Christer Holmberg (JO/LMF) wrote: > I am also confused that people seem to think that INFOs will start > flying around for no reason, without the sender having any clue about > whether the receiver will understand them or not. As we have > discussed, there ARE mechanisms in SIP to negotiate what content > types etc entities support. Yes, MAYBE we need to extend that (e.g. > being able to indicate which methods can be used to carry a specific > content type), if what we have is not enough. But, to me that is not > the same thing has having "tons of problem". There is a big difference between, "I can support this format", and "I am interested in having you send me events in this format". This is why we didn't go with the INFO method for DTMF. Since DTMF would already be arriving at the UAS in the form of 2833, the primary entities needing signaling-based solutions are applications not on the media path. But, we only want to send such signaling when there is an application that is interested. This is exactly what SUB/NOT is for - to ask for notifications of events. Furthermore, by using a separate dialog we could have the notifications sent just to the interested application server, so that the proxies on the path of the original dialog don't need to see INFO messages flying by if they weren't interested. Consider further the other UA in the call. If it supports both DTMF-over-INFO and RFC2833, what does it mean to get both? If you generate DTMF on receipt of INFO, you stand a real risk of generating double DTMF which is very bad. You avoid this problem if you only send DTMF over signaling when asked; this way the thing getting the rfc2833 doesn't ask for it. Using SUB/NOT also allowed the application to customize when it would get a notification. So for example an app that needed each digit as it was pressed could get them immediately. One only needing them after some pattern was matched could only get it then. This was also a perfect match for SUB/NOT. So there are serious technical limitations to carrying DTMF over INFO. Sure, it can 'work', but it is very suboptimal and can cause problems. As for a general INFO usage, my opinion is unchanged on this. We have numerous methods for extending SIP by adding new headers and methods and event packages. Can you demonstrate a use case where one of these extensibility mechanisms is not sufficient for some use case? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 19 20:13:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0npQ-00066P-SM; Tue, 19 Jun 2007 20:13:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0npP-00066C-MO for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 20:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0npP-000650-An for sip@ietf.org; Tue, 19 Jun 2007 20:13:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0npO-0005HF-V9 for sip@ietf.org; Tue, 19 Jun 2007 20:13:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 20:13:12 -0400 X-IronPort-AV: i="4.16,440,1175486400"; d="scan'208"; a="124079200:sNHT85289058574" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5K0DAt9032571; Tue, 19 Jun 2007 20:13:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5K0DA5f026640; Wed, 20 Jun 2007 00:13:10 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:13:10 -0400 Received: from [63.115.24.215] ([10.86.243.145]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:13:10 -0400 Message-ID: <46787112.5000900@cisco.com> Date: Tue, 19 Jun 2007 20:13:06 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Johns Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 00:13:10.0173 (UTC) FILETIME=[C8E454D0:01C7B2CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3464; t=1182298390; x=1183162390; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20on=20draft-ietf-sip-ice-option-tag-01 |Sender:=20 |To:=20Kevin=20Johns=20; bh=zYwfYI/RZ9i7iCyS19WKyXS95CdsVzAK+uRE22oiZ0A=; b=dryQmiy4bOXAxqyPV4d1HuogqVbpY0AFT7yuKzxqqSoCzL9ZQDHu/sJY/CrOeVeVS3lH9MGv Tdjc47uHm9GGK0h3YDpz3AOMiEOjHvDUM36B4Wu9kYuO8TGp2iEzXBN8; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is part of why I think we need sips - we have countless drafts which reference it as the security mechanism to use when you want to protect against modification of signaling messages by off-path attackers. Thus, I think this draft should continue the current policy and reference sips. Thanks, Jonathan R. Kevin Johns wrote: > Keith, > > I have reviewed this document. The only question I have is its reference > to SIPS as a way to mitigate some security risks. Given the status of > SIPS I was unsure whether it should be listed as a mechanism for > addressing possible security risks? Otherwise this document looks good. > > Regards, > Kevin Johns > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Friday, April 13, 2007 9:42 AM > To: IETF SIP List > Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 > > A reminder that you now have just one week to reply on this WGLC. > > It would be nice to have some indication that people have even looked at > this reasonably short document. > > Remember, if we cannot get this document out of the door, then we cannot > get ICE out of the door either. > > Regards > > Keith > > >>-----Original Message----- >>From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] >>Sent: Thursday, March 29, 2007 6:09 PM >>To: IETF SIP List >>Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 >> >>(As WG chair) >> >>WGLC has just commenced in the MMUSIC WG on >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt >> >>This is to announce a parallel WGLC on >>http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option- >>tag-01.txt >> >>The dates of the WGLC are identical to those in MMUSIC. >>Therefore please provide responses to the WGLC by 20th April 2007. >> >>Comments on the SIP document should be provided to the SIP list only, >>and to the editor. Please provide comments clearly indicating the page > > >>or section, the text to be changed (copy and paste!), and the proposed > > >>modification if possible. >> >>Regards >> >>Keith >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 19 20:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nsV-0000Bs-FI; Tue, 19 Jun 2007 20:16:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0nsU-0000Bn-CT for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 20:16:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nsU-0000Bf-2s for sip@ietf.org; Tue, 19 Jun 2007 20:16:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nsS-0006oD-Qr for sip@ietf.org; Tue, 19 Jun 2007 20:16:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2007 20:16:52 -0400 X-IronPort-AV: i="4.16,440,1175486400"; d="scan'208"; a="63205316:sNHT47167430" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5K0GqMn018382; Tue, 19 Jun 2007 20:16:52 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K0GdBi003648; Wed, 20 Jun 2007 00:16:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:16:46 -0400 Received: from [63.115.24.215] ([10.86.243.145]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:16:46 -0400 Message-ID: <467871ED.3050801@cisco.com> Date: Tue, 19 Jun 2007 20:16:45 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: peter_blatherwick@mitel.com Subject: Re: Nits RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 00:16:46.0191 (UTC) FILETIME=[49A60FF0:01C7B2D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1074; t=1182298612; x=1183162612; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20Nits=20RE=3A=20[Sip]=20WGLC=20on=20draft-ietf-sip-ice -option-tag-01 |Sender:=20 |To:=20peter_blatherwick@mitel.com; bh=glxbXx6MGrDAX3i31iKtXnWBFQMRyIsd9dD7XYwXaNo=; b=lNk2d3nIyJ6TBXrfcHwBishp2cVmEmTWVllHvnYm2MTXz983ENfshB/E/lexXxMWZDyeGD98 /oJnW5zjMweluAf05cUDmARRdNdRN/YiIj/+t6rrYIGDe/DU0Il848G2; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Thanks for the comments. Brief replies below. peter_blatherwick@mitel.com wrote: > > Read it, and looks good except for a few truly minor nits. > > - sec 4, 1st sentence, for consistency seems the tag should be in > quotes, ie "The "sip.ice" media feature tag ..." > > - sec 6, 2nd paragraph, last sentence should read "... using the SIP*S* > mechanism. " (Missing the S in SIPS) Both fixed. > > - sec 7.2, for consistency with sec 7.1 should the tag name be give > simply by "Name: sip.ice" (or sec 7.1 spell it all out as in sec 7.2) These two sections are based on different registries - one is for SIP option tags and the other for media feature tags. So the names are different. Thanks, Jonahtan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 19 20:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nxF-0003hF-EA; Tue, 19 Jun 2007 20:21:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0nxE-0003h9-9v for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 20:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nxE-0003gz-0H for sip@ietf.org; Tue, 19 Jun 2007 20:21:48 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nxC-0008MC-OF for sip@ietf.org; Tue, 19 Jun 2007 20:21:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 20:21:46 -0400 X-IronPort-AV: i="4.16,440,1175486400"; d="scan'208"; a="124079757:sNHT47336294" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5K0Lk9k020050; Tue, 19 Jun 2007 20:21:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K0LjBe004817; Wed, 20 Jun 2007 00:21:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:21:45 -0400 Received: from [63.115.24.215] ([10.86.243.145]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:21:45 -0400 Message-ID: <46787318.4070604@cisco.com> Date: Tue, 19 Jun 2007 20:21:44 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <000801c77de7$83af9c70$0601a8c0@BEMBUSTER> In-Reply-To: <000801c77de7$83af9c70$0601a8c0@BEMBUSTER> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 00:21:45.0283 (UTC) FILETIME=[FBEBE130:01C7B2D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1030; t=1182298906; x=1183162906; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20on=20draft-ietf-sip-ice-option-tag-01 |Sender:=20 |To:=20Jeroen=20van=20Bemmel=20; bh=1W8J10+EZzC22gs/aocKZwHT5VeuQcIijab0wTvsUb0=; b=hVRGiTnGbFAtm7ixI3CAQIFZ5OnUSs1I0blx1FRYkCrcB//QbXn6obrSiiz9Zg1Mf/h9epDd 5Q7ltWTFHNr+DCrOdbgoHvcnQ4MUt3wbwZnTBFglXobYI9AFAjjyY+TJ; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IETF SIP List , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jeroen van Bemmel wrote: > One minor comment on section 5 ("SHOULD NOT be used in conjunction with > the Supported header field"): in case an OPTIONS request is received, > surely the UAS is expected to respond with Supported: ice in its > response? No. The media feature tag is used there instead. Section 4 calls this out, as it mentions that the media feature tag is used on REGISTER requests and OPTIONS responses. If so, that would be worth mentioning explicitly as an > exception to the "SHOULD NOT" Actually I'll mention it as part of that restriction rather than an inclusion. I'm trying to avoid having more than one way of signaling something. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 19 20:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oEx-0006Qc-4i; Tue, 19 Jun 2007 20:40:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0oEt-0006NM-Eq for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 20:40:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oEt-0006NB-3U; Tue, 19 Jun 2007 20:40:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0oEs-0005Py-N1; Tue, 19 Jun 2007 20:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 926B526E77; Wed, 20 Jun 2007 00:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0oEs-0001xg-G2; Tue, 19 Jun 2007 20:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jun 2007 20:40:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-ice-option-tag-02.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@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 : Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-ice-option-tag-02.txt Pages : 8 Date : 2007-06-19 This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a UA to communicate to its registrar that it supports ICE. The option tag allows a User Agent (UA) to require support for ICE in order for a call to proceed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option-tag-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-ice-option-tag-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-ice-option-tag-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-06-19203412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-ice-option-tag-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-ice-option-tag-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-06-19203412.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Tue Jun 19 21:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0p8X-0001xw-GB; Tue, 19 Jun 2007 21:37:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0p8V-0001xr-SU for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 21:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0p8V-0001xj-J0 for sip@ietf.org; Tue, 19 Jun 2007 21:37:31 -0400 Received: from smtpauth01.csee.onr.siteprotect.com ([64.26.60.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0p8U-0008Hu-7c for sip@ietf.org; Tue, 19 Jun 2007 21:37:31 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth01.csee.onr.siteprotect.com (Postfix) with ESMTP id 445441C803D; Tue, 19 Jun 2007 20:27:55 -0500 (CDT) Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 From: "Frank W. Miller" To: Jonathan Rosenberg In-Reply-To: <46787112.5000900@cisco.com> References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> Content-Type: text/plain Date: Tue, 19 Jun 2007 19:37:19 -0600 Message-Id: <1182303439.3381.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Kevin Johns X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org With all due respect, seriously. This part of why you think we need sips argument reduces to: its been there for a long time and it hasn't been fixed it so it provides real end-to-end security, and since there's nothing else, other draft writers have been forced to reference it so lets just maintain the status quo. Again, with all due respect, I don't think this is a reasonable argument. The fundamental problem with sips is that its not end-to-end. If it were end-to-end, there would be no discussion it would just be getting implemented and used. How long will it be before those "in control" of the standards realize that there is a pressing need, indeed a requirement, among the users of the standard for true end-to-end security and put something that "they" think is OK in place to address it? Faithfully submitted, Dougla... *cough* FM On Tue, 2007-06-19 at 20:13 -0400, Jonathan Rosenberg wrote: > This is part of why I think we need sips - we have countless drafts > which reference it as the security mechanism to use when you want to > protect against modification of signaling messages by off-path attackers. > > Thus, I think this draft should continue the current policy and > reference sips. > > Thanks, > Jonathan R. > > Kevin Johns wrote: > > > Keith, > > > > I have reviewed this document. The only question I have is its reference > > to SIPS as a way to mitigate some security risks. Given the status of > > SIPS I was unsure whether it should be listed as a mechanism for > > addressing possible security risks? Otherwise this document looks good. > > > > Regards, > > Kevin Johns > > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Friday, April 13, 2007 9:42 AM > > To: IETF SIP List > > Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 > > > > A reminder that you now have just one week to reply on this WGLC. > > > > It would be nice to have some indication that people have even looked at > > this reasonably short document. > > > > Remember, if we cannot get this document out of the door, then we cannot > > get ICE out of the door either. > > > > Regards > > > > Keith > > > > > >>-----Original Message----- > >>From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >>Sent: Thursday, March 29, 2007 6:09 PM > >>To: IETF SIP List > >>Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 > >> > >>(As WG chair) > >> > >>WGLC has just commenced in the MMUSIC WG on > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > >> > >>This is to announce a parallel WGLC on > >>http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option- > >>tag-01.txt > >> > >>The dates of the WGLC are identical to those in MMUSIC. > >>Therefore please provide responses to the WGLC by 20th April 2007. > >> > >>Comments on the SIP document should be provided to the SIP list only, > >>and to the editor. Please provide comments clearly indicating the page > > > > > >>or section, the text to be changed (copy and paste!), and the proposed > > > > > >>modification if possible. > >> > >>Regards > >> > >>Keith > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use > >>sip-implementors@cs.columbia.edu for questions on current sip Use > >>sipping@ietf.org for new developments on the application of sip > >> > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > sip-implementors@cs.columbia.edu for questions on current sip Use > > sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 21:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0pAH-0002gt-4C; Tue, 19 Jun 2007 21:39:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0pAF-0002go-7Q for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 21:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0pAE-0002gg-U3 for sip@ietf.org; Tue, 19 Jun 2007 21:39:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0pAE-0008L7-Js for sip@ietf.org; Tue, 19 Jun 2007 21:39:18 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2007 18:39:17 -0700 X-IronPort-AV: i="4.16,440,1175497200"; d="scan'208"; a="168418061:sNHT48360159" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5K1dG2t011569; Wed, 20 Jun 2007 03:39:16 +0200 Received: from dwingwxp ([10.32.240.194]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K1dADR017828; Wed, 20 Jun 2007 01:39:11 GMT From: "Dan Wing" To: "'DRAGE, Keith \(Keith\)'" , "'IETF SIP List'" Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 19 Jun 2007 18:39:09 -0700 Message-ID: <0dfc01c7b2db$d001cf70$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8AFBYEcQ In-Reply-To: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2161; t=1182303556; x=1183167556; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=BKLh/Ukxyw4Tfy+CiiJ2ZZSm8oNLljHv3vnVK3XV2HI=; b=oND7yBKtEdzgONmojMN0gO/KY4eJFMMZ2TdoGQBECh7QGqfZqyLE2Su6YC8BG7yTiyBtnvHF sw2d3ylII8EadmNe0QvcVmHZK/MqvpJCC8Tcjq3+sH272i0qLiypjnXh; Authentication-Results: ams-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > - whether this represents a problem space that the working group > should draft requirements on? Yes; it is desirable and useful to provide an authentication mechanism that uses certificates to authenticate a registrar to its UA and a SIP UA to its registrar, rather than the existing Digest mechanism that uses a shared secret between the UA and its registrar. > - whether the problem space exists but is something slightly > different, and if so what is that problem space? > > - whether there is a more general problem that the security area > should be addressing, rather than the SIP group addressing something > specific? I expect you're referring to HTTP, as HTTP is where SIP derived its Digest authentication from. I don't believe HTTP has any need or interest in using certificates for client authentication; however, as you know, there is some interest in considering how HTTP's authentication can be 'fixed' (modernized). > - based on your answers to the first three questions, whether this > draft is essentially in the right direction to be adopted as the WG > draft assuming we create the charter item, or whether we need to seek > some other input draft? draft-dotson-sip-certificate-auth-03 seems suitable in capturing requirements. > - and finally, whether (assuming we go ahead with this work) there > is any work in any other IETF WG that we should take account of? During the discussion of the HTTPbis BoF, http://lists.w3.org/Archives/Public/ietf-http-wg there were some people that suggested RFC2617 (which defines HTTP's Basic and Digest authentication) also be revised. This may have some bearing on SIP, if it is decided that HTTPbis's charter will include a revision of RFC2617. -d > Regards > > Keith > > > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 19 23:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0qR4-00088e-TV; Tue, 19 Jun 2007 23:00:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0qR3-00088W-Bb for sip-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 23:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0qR2-00088O-Vf for sip@ietf.org; Tue, 19 Jun 2007 23:00:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0qR1-0006gP-OK for sip@ietf.org; Tue, 19 Jun 2007 23:00:44 -0400 Received: from 24-155-155-32.dyn.grandenetworks.net ([24.155.155.32] helo=[192.168.1.101]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I0qQz-0002bi-Ne; Tue, 19 Jun 2007 22:00:41 -0500 In-Reply-To: <1182303439.3381.11.camel@localhost.localdomain> References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 Date: Tue, 19 Jun 2007 22:00:25 -0500 To: Frank W. Miller X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , Kevin Johns , "Drage, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 19, 2007, at 8:37 PM, Frank W. Miller wrote: > > Again, with all due respect, I don't think this is a reasonable > argument. The fundamental problem with sips is that its not end-to- > end. > If it were end-to-end, there would be no discussion it would just be > getting implemented and used. How long will it be before those "in > control" of the standards realize that there is a pressing need, > indeed > a requirement, among the users of the standard for true end-to-end > security and put something that "they" think is OK in place to address > it? > Ah, sipsec? Of course, if you think Vijay, Francois and I are "in control" of standards, I have to tell you it's the other way around. -- 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 sip-bounces@ietf.org Wed Jun 20 00:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0rkE-0002Nk-Vr; Wed, 20 Jun 2007 00:24:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0rkC-0002M5-Ov for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 00:24:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0rkC-0002Lx-8q for sip@ietf.org; Wed, 20 Jun 2007 00:24:36 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0rkB-0007wJ-2e for sip@ietf.org; Wed, 20 Jun 2007 00:24:36 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 5FD3A75804A; Tue, 19 Jun 2007 23:24:34 -0500 (CDT) Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 From: "Frank W. Miller" To: Dean Willis In-Reply-To: References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 19 Jun 2007 22:24:23 -0600 Message-Id: <1182313463.3381.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Kevin Johns X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Tue, 2007-06-19 at 22:00 -0500, Dean Willis wrote: > Ah, sipsec? > I think the sipsec draft is quite reasonable. It wasn't completely clear to me from Figures 2 and 3 whether the session signaling, i.e. post-CONNECT, was traversing the proxies or not? I would prefer to see the CONNECT transaction somehow enable the UAC and UAS to signal directly between each other without proxies from then on. Is that what is intended or is the subsequent signaling still passing through the intermediate proxies? Thanks, FM _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 04:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vDO-00046S-Ki; Wed, 20 Jun 2007 04:06:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0vDM-0003w5-F8 for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 04:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vDM-0003v6-1y for sip@ietf.org; Wed, 20 Jun 2007 04:06:56 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0vDK-0002wz-F7 for sip@ietf.org; Wed, 20 Jun 2007 04:06:56 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JJX0009WD767E@siemenscomms.co.uk> for sip@ietf.org; Wed, 20 Jun 2007 09:06:42 +0100 (BST) Date: Wed, 20 Jun 2007 09:06:51 +0100 From: "Elwell, John" Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 In-reply-to: <1ECE0EB50388174790F9694F77522CCF10EE3CFA@zrc2hxm0.corp.nortel.com> To: Francois Audet , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D019E9F1@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceyxHxs1Kmx5P/WRoGSZU2TXmO3/wAANFuAABL3hgA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> <46785E08.1030203@cisco.com> <1ECE0EB50388174790F9694F77522CCF10EE3CFA@zrc2hxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org But maybe the INVITE could contain minimal information, e.g., an SDP offer with no media. Note that METHOD/Replaces cannot be sent to a UAS during an early dialog, so CONNECT/Replaces would have to be sent in the backwards direction. Also we would need to consider what happens if the regular INVITE arrives at a proxy or UAS that does not support sipsec. May need to use Require/Proxy-Require, or maybe we could achieve some sort of best effort security by not requiring sipsec support. John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 19 June 2007 23:59 > To: Paul Kyzivat; Elwell, John > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > > Yeah, we tought about that. > > The problem is that the INVITE is loaded with too much > information that > would then > leak. > > The idea of the CONNECT is that it would have the bare > minimum to route. > Then the full > blown end-to-end secure INVITE (with the SDP) could be exchanged. > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, June 19, 2007 15:52 > > To: Elwell, John > > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF SIP > > List; Dean Willis > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > > > > > > Elwell, John wrote: > > > Vijay, > > > > > > This deals with straightforward forking scenarios. What > > about a proxy > > > that is scripted to fork in parallel to two destinations, > > and then, if > > > they both fail to answer, fork to a third destination? Or a > > proxy that > > > is scripted to forward to one destination, and then, if > it fails to > > > answer after a certain time, fork to a second location without > > > cancelling the request at the first destination? > > > > Some of these cases can be handled by attaching q-values to > > the contacts in the 3xx, if the UA cooperates by doing the > > ones with equal q-value in parallel and the ones with > > different q-values in descending q-value order. > > > > But it doesn't deal with more complex policy. And of course > > if this is done by the callee's home proxy then it can be > > certain the policy is followed. If it is deferred to the > > caller then you can't be sure. > > > > Of course this is to some extent a battle over who's policy > > should be followed, and there is no single right answer here. > > But its probably safe to assume that many callee's won't want > > to give up control over this. > > > > An alternative I suggested earlier, that nobody commented on, > > is to start out with a regular INVITE, which can potentially > > fork. After a dialog is established, do a CONNECT/Replaces to > > establish a secure session to the target. This could be done > > during an early dialog, or after the final dialog is > > established. This could be triggered by presence of > > "Supported:sipsec" in the response. > > > > Paul > > > > > John > > > > > >> -----Original Message----- > > >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > >> Sent: 19 June 2007 17:35 > > >> To: Francois Audet > > >> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John > > >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > >> > > >> Francois Audet wrote: > > >>> Agreed. > > >>> > > >>> Basically, say the "CONNECT" ended up in 3 different > > >> directions after > > >>> a 3XX with 3 contacts. The UAC would set up the end-to-end TLS > > >>> connections from the UAC to the 3 contacts. > > >>> > > >>> Then the INVITEs have no intermediaries, so they can't fork. > > >> OK; returning a 3xx seems to be preferred. Then, so that we can > > >> update the next revision appropriately, here is some rough text: > > >> > > >> A proxy that accesses a location service to route a CONNECT > > >> request and discovers more than one contact bound to that > > >> AoR MUST format a 3xx-class response with the contacts > > discovered > > >> from the location service. This response is subsequently > > >> sent upstream. > > >> > > >> A proxy that receives a 3xx-class response as a result of > > >> proxying a CONNECT request downstream MUST NOT recurse on the > > >> receipt of the 3xx-class response. Instead, it MUST send the > > >> response upstream. > > >> > > >> When a user agent receives a 3xx-class response from its > > >> downstream server with multiple Contact headers, it MAY decide > > >> to fork in parallel or in serial depending on its software > > >> capabilities and configuration policies. Alternatively, it > > >> MAY analyze the received Contact headers and choose to send it > > >> to a particular destination that it suspects would stand the > > >> best chance of eliciting a successful response. > > >> > > >> OK? > > >> > > >> - vijay > > >> -- > > >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > >> WWW: http://www.alcatel-lucent.com/bell-labs > > >> > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 06:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xfe-0000Nl-AV; Wed, 20 Jun 2007 06:44:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I0xfb-0000Ng-J1 for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 06:44:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xfb-0000NY-8b for sip@ietf.org; Wed, 20 Jun 2007 06:44:15 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xfY-000357-Nr for sip@ietf.org; Wed, 20 Jun 2007 06:44:15 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5KAi9Yr004524; Wed, 20 Jun 2007 12:44:10 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5KAi9Dg023240; Wed, 20 Jun 2007 12:44:09 +0200 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:44:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Wed, 20 Jun 2007 12:44:05 +0200 Message-ID: <6A18D243963B7447AC1A36583F78EEDA01F7EC43@MCHP7I6A.ww002.siemens.net> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8AFUw3Dg References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> From: "Fries, Steffen" To: "DRAGE, Keith (Keith)" , "IETF SIP List" X-OriginalArrivalTime: 20 Jun 2007 10:44:09.0617 (UTC) FILETIME=[EEE10810:01C7B327] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org HI, > - whether this represents a problem space that the working group > should draft requirements on? certificate based authentication from my point of view is useful to increase the security of the=20 user authentication, which is currently achieved by HTTP digest. >=20 > - whether the problem space exists but is something slightly > different, and if so what is that problem space? >=20 > - whether there is a more general problem that the security area > should be addressing, rather than the SIP group addressing=20 > something specific? as SIP borrows the digest authentication from HTTP, it might also be possible to enhance the HTTP authentication and re-use it in SIP for the certificate based authentication. As Dan already wrote a potential HTTPbis might capture this approach. > - based on your answers to the first three questions, whether this > draft is essentially in the right direction to be adopted as=20 > the WG draft assuming we create the charter item, or whether=20 > we need to seek some other input draft? this draft outlines the requirements for certificate based authentication for SIP and should therefore be used as a requirements document. I guess it does not necessarily determine, if the solution is being defined in SIP as opposed to define the base solution for HTTP and derive a solution in SIP >=20 > - and finally, whether (assuming we go ahead with this work) there > is any work in any other IETF WG that we should take account of? see Dans reference Regards Steffen >=20 >=20 > Regards >=20 > Keith >=20 >=20 >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 09:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10Cb-0001OJ-Kp; Wed, 20 Jun 2007 09:26:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I10CZ-0001NF-U0 for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 09:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10CZ-0001N7-KW for sip@ietf.org; Wed, 20 Jun 2007 09:26:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10CY-0007z9-9C for sip@ietf.org; Wed, 20 Jun 2007 09:26:27 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2007 06:26:05 -0700 X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="168727817:sNHT509912586" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5KDQ5ij008187; Wed, 20 Jun 2007 06:26:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5KDPmtV006465; Wed, 20 Jun 2007 13:25:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 06:25:48 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 06:25:47 -0700 Message-ID: <46792ADA.9010304@cisco.com> Date: Wed, 20 Jun 2007 09:25:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> In-Reply-To: <1182303439.3381.11.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2007 13:25:47.0815 (UTC) FILETIME=[83749B70:01C7B33E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1262; t=1182345965; x=1183209965; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20on=20draft-ietf-sip-ice-option-tag-01 |Sender:=20; bh=/xat2fgHxAiE5qWP39RZJEupeDOM0LO2ehzJ2/lB77s=; b=ia0ZNh5aE/imGRcPHXpDHXMJ0VWu/rN3dVaSBFg90rn+BAdftbaAoAo9NnnnT76SdLjdpcoo tWS/vBut54Z/4N2GfaHU2OnTUw+GEmA9rhNTDsK+uPcm5MZfrKdHRerv; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: IETF SIP List , "Drage, Keith \(Keith\)" , Kevin Johns X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: > > With all due respect, seriously. > > This part of why you think we need sips argument reduces to: its been > there for a long time and it hasn't been fixed it so it provides real > end-to-end security, and since there's nothing else, other draft writers > have been forced to reference it so lets just maintain the status quo. Of course that is not what I am saying. What I am saying is that one of our key security needs is a technique that allows us to protect signaling from off-path attackers. That includes prevention against eavesdropping and protection against modification of signaling messages. SIPS meets that need. In any case I don't want to turn yet another thread into a sips bashing one. THis thread is about ice-option-tag. So unless you are suggesting changes to sip-ice-option-tag, I'd like to move forward with that document. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Wed Jun 20 10:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10qn-0000Pd-Ul; Wed, 20 Jun 2007 10:08:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I10qm-0000PS-Ho for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 10:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10qm-0000PK-7k for sip@ietf.org; Wed, 20 Jun 2007 10:08:00 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10qj-0002tc-UK for sip@ietf.org; Wed, 20 Jun 2007 10:08:00 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5KE7tIm018144; Wed, 20 Jun 2007 09:07:55 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5KE7ga07519; Wed, 20 Jun 2007 09:07:42 -0500 (CDT) Message-ID: <467934AD.7020708@alcatel-lucent.com> Date: Wed, 20 Jun 2007 09:07:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank W. Miller" Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> <1182313463.3381.21.camel@localhost.localdomain> In-Reply-To: <1182313463.3381.21.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: IETF SIP List , Kevin Johns , "Drage, Keith \(Keith\)" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank W. Miller wrote: > On Tue, 2007-06-19 at 22:00 -0500, Dean Willis wrote: > >>Ah, sipsec? > > I think the sipsec draft is quite reasonable. > > It wasn't completely clear to me from Figures 2 and 3 whether the > session signaling, i.e. post-CONNECT, was traversing the proxies or not? > I would prefer to see the CONNECT transaction somehow enable the UAC and > UAS to signal directly between each other without proxies from then on. > Is that what is intended or is the subsequent signaling still passing > through the intermediate proxies? Frank: In certain cases -- peers behind NAT, for instance -- you will have to keep the proxies in the path. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 10:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11Hq-0002uR-BU; Wed, 20 Jun 2007 10:35:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I11Ho-0002u5-Kz for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 10:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11Ho-0002tT-BI for sip@ietf.org; Wed, 20 Jun 2007 10:35:56 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I11Hn-0004IM-3G for sip@ietf.org; Wed, 20 Jun 2007 10:35:56 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 76F1C758046; Wed, 20 Jun 2007 09:35:54 -0500 (CDT) From: "Frank W. Miller" To: "Vijay K. Gurbani" In-Reply-To: <467934AD.7020708@alcatel-lucent.com> References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> <1182313463.3381.21.camel@localhost.localdomain> <467934AD.7020708@alcatel-lucent.com> Content-Type: text/plain Date: Wed, 20 Jun 2007 08:35:42 -0600 Message-Id: <1182350142.3134.14.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: IETF SIP List , Dean Willis Subject: [Sip] sipsec draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Changing the subject name... Agreed, but really only for cases where ICE would result in use of a relay correct? In all other cases, the CONNECT path would establish the "way in" to the UAS through the NAT for the subsequent INVITE to come in directly would it not? Relay is only required for a percentage of connections. It's also my hope that with the BEHAVE work, NAT vendors will over time make their NATs more friendly to SIP-like services. Ultimately, what I'm hoping is that the use of relays becomes less necessary rather than more necessary. While I'm sure that despite IPv6, NATS will be around forever, I do believe in the basic design tenet that underlies the Internet architecture, the principle of e2e. That principle in this instance I believe should nudge us into trying to design for direct UAC to UAS signaling when possible. I'm all for this tunneling mechanism, it may be a happy medium, but my architectural sense is that once the two endpoints have found each other, the best way to really insure e2e security is to have them signal each other directly. Thanks, FM On Wed, 2007-06-20 at 09:07 -0500, Vijay K. Gurbani wrote: > Frank W. Miller wrote: > > On Tue, 2007-06-19 at 22:00 -0500, Dean Willis wrote: > > > >>Ah, sipsec? > > > > I think the sipsec draft is quite reasonable. > > > > It wasn't completely clear to me from Figures 2 and 3 whether the > > session signaling, i.e. post-CONNECT, was traversing the proxies or not? > > I would prefer to see the CONNECT transaction somehow enable the UAC and > > UAS to signal directly between each other without proxies from then on. > > Is that what is intended or is the subsequent signaling still passing > > through the intermediate proxies? > > Frank: In certain cases -- peers behind NAT, for instance -- you will > have to keep the proxies in the path. > > Thanks, > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 12:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13LD-0008Lo-0B; Wed, 20 Jun 2007 12:47:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I13LB-0008Lj-KE for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:47:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13LB-0008La-9W for sip@ietf.org; Wed, 20 Jun 2007 12:47:33 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13L9-0004w7-RM for sip@ietf.org; Wed, 20 Jun 2007 12:47:33 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KGlRO17765; Wed, 20 Jun 2007 16:47:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Wed, 20 Jun 2007 11:47:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10F3AB60@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D019E9F1@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: AceyxHxs1Kmx5P/WRoGSZU2TXmO3/wAANFuAABL3hgAAEj874A== References: <4671B5F3.1050606@alcatel-lucent.com> <005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER> <4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com> <4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com> <46772959.5010407@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com> <467805A1.5090406@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> <46785E08.1030203@cisco.com> <1ECE0EB50388174790F9694F77522CCF10EE3CFA@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D019E9F1@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: IETF SIP List , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The advantage of the CONNECT method is that we don't have to change the behavior associated with INVITE. And we don't have to change what is the mandatory content of INVITE either. (It's not just the SDP). For example, with CONNECT we want to mandate "no proxy forking". > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Wednesday, June 20, 2007 01:07 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: IETF SIP List; Dean Willis > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 >=20 > But maybe the INVITE could contain minimal information, e.g.,=20 > an SDP offer with no media. Note that METHOD/Replaces cannot=20 > be sent to a UAS during an early dialog, so CONNECT/Replaces=20 > would have to be sent in the backwards direction. >=20 > Also we would need to consider what happens if the regular=20 > INVITE arrives at a proxy or UAS that does not support=20 > sipsec. May need to use Require/Proxy-Require, or maybe we=20 > could achieve some sort of best effort security by not=20 > requiring sipsec support. >=20 > John >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 19 June 2007 23:59 > > To: Paul Kyzivat; Elwell, John > > Cc: IETF SIP List; Dean Willis > > Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 > >=20 > > Yeah, we tought about that. > >=20 > > The problem is that the INVITE is loaded with too much information=20 > > that would then leak. > >=20 > > The idea of the CONNECT is that it would have the bare minimum to=20 > > route. > > Then the full > > blown end-to-end secure INVITE (with the SDP) could be exchanged.=20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, June 19, 2007 15:52 > > > To: Elwell, John > > > Cc: Vijay K. Gurbani; Audet, Francois (SC100:3055); IETF=20 > SIP List;=20 > > > Dean Willis > > > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > >=20 > > >=20 > > >=20 > > > Elwell, John wrote: > > > > Vijay, > > > >=20 > > > > This deals with straightforward forking scenarios. What > > > about a proxy > > > > that is scripted to fork in parallel to two destinations, > > > and then, if > > > > they both fail to answer, fork to a third destination? Or a > > > proxy that > > > > is scripted to forward to one destination, and then, if > > it fails to > > > > answer after a certain time, fork to a second location without=20 > > > > cancelling the request at the first destination? > > >=20 > > > Some of these cases can be handled by attaching q-values to the=20 > > > contacts in the 3xx, if the UA cooperates by doing the ones with=20 > > > equal q-value in parallel and the ones with different q-values in=20 > > > descending q-value order. > > >=20 > > > But it doesn't deal with more complex policy. And of=20 > course if this=20 > > > is done by the callee's home proxy then it can be certain=20 > the policy=20 > > > is followed. If it is deferred to the caller then you=20 > can't be sure. > > >=20 > > > Of course this is to some extent a battle over who's=20 > policy should=20 > > > be followed, and there is no single right answer here. > > > But its probably safe to assume that many callee's won't want to=20 > > > give up control over this. > > >=20 > > > An alternative I suggested earlier, that nobody commented=20 > on, is to=20 > > > start out with a regular INVITE, which can potentially=20 > fork. After a=20 > > > dialog is established, do a CONNECT/Replaces to establish=20 > a secure=20 > > > session to the target. This could be done during an early=20 > dialog, or=20 > > > after the final dialog is established. This could be triggered by=20 > > > presence of "Supported:sipsec" in the response. > > >=20 > > > Paul > > >=20 > > > > John > > > >=20 > > > >> -----Original Message----- > > > >> From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > > > >> Sent: 19 June 2007 17:35 > > > >> To: Francois Audet > > > >> Cc: IETF SIP List; Paul Kyzivat; Dean Willis; Elwell, John > > > >> Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 > > > >> > > > >> Francois Audet wrote: > > > >>> Agreed. > > > >>> > > > >>> Basically, say the "CONNECT" ended up in 3 different > > > >> directions after > > > >>> a 3XX with 3 contacts. The UAC would set up the=20 > end-to-end TLS=20 > > > >>> connections from the UAC to the 3 contacts. > > > >>> > > > >>> Then the INVITEs have no intermediaries, so they can't fork. > > > >> OK; returning a 3xx seems to be preferred. Then, so=20 > that we can=20 > > > >> update the next revision appropriately, here is some=20 > rough text: > > > >> > > > >> A proxy that accesses a location service to route a CONNECT > > > >> request and discovers more than one contact bound to that > > > >> AoR MUST format a 3xx-class response with the contacts > > > discovered > > > >> from the location service. This response is subsequently > > > >> sent upstream. > > > >> > > > >> A proxy that receives a 3xx-class response as a result of > > > >> proxying a CONNECT request downstream MUST NOT=20 > recurse on the > > > >> receipt of the 3xx-class response. Instead, it=20 > MUST send the > > > >> response upstream. > > > >> > > > >> When a user agent receives a 3xx-class response from its > > > >> downstream server with multiple Contact headers, it=20 > MAY decide > > > >> to fork in parallel or in serial depending on its software > > > >> capabilities and configuration policies. Alternatively, it > > > >> MAY analyze the received Contact headers and choose=20 > to send it > > > >> to a particular destination that it suspects would stand the > > > >> best chance of eliciting a successful response. > > > >> > > > >> OK? > > > >> > > > >> - vijay > > > >> -- > > > >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > > >> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > > >> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > > >> WWW: http://www.alcatel-lucent.com/bell-labs > > > >> > > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 12:54:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13SH-0006av-Sx; Wed, 20 Jun 2007 12:54:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I13SH-0006aq-3l for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13SG-0006ai-QV for sip@ietf.org; Wed, 20 Jun 2007 12:54:52 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13SG-0005ud-FO for sip@ietf.org; Wed, 20 Jun 2007 12:54:52 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5KGskM22016; Wed, 20 Jun 2007 16:54:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 Date: Wed, 20 Jun 2007 11:54:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF10F3AB8C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1182303439.3381.11.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 Thread-Index: Acey26iM6+6G5XpDTnKnd9tI8Px4wAAf13TQ References: <5D1A7985295922448D5550C94DE29180F20879@DEEXC1U01.de.lucent.com> <5D1A7985295922448D5550C94DE29180FFE2E4@DEEXC1U01.de.lucent.com> <9AAEDF491EF7CA48AB587781B8F5D7C639C6@srvxchg3.cablelabs.com> <46787112.5000900@cisco.com> <1182303439.3381.11.camel@localhost.localdomain> From: "Francois Audet" To: "Frank W. Miller" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Frank, If you have a solution in mind, please let us know. You are just as much "in control" of standards as anybody else in this group. SIPS is indeed not end-to-end. Yes, we know that. SIP in general is also not end-to-end. End-to-end comes at a cost, as we've seen with S/MIME, MIKEY and others. There are environments where it is easier and more=20 appropriate to use than others. > -----Original Message----- > From: Frank W. Miller [mailto:fwmiller@cornfed.com]=20 > Sent: Tuesday, June 19, 2007 18:37 > To: Jonathan Rosenberg > Cc: IETF SIP List; Drage, Keith (Keith); Kevin Johns > Subject: Re: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 >=20 >=20 >=20 > With all due respect, seriously. >=20 > This part of why you think we need sips argument reduces to:=20 > its been there for a long time and it hasn't been fixed it so=20 > it provides real end-to-end security, and since there's=20 > nothing else, other draft writers have been forced to=20 > reference it so lets just maintain the status quo. =20 >=20 > Again, with all due respect, I don't think this is a=20 > reasonable argument. The fundamental problem with sips is=20 > that its not end-to-end. > If it were end-to-end, there would be no discussion it would=20 > just be getting implemented and used. How long will it be=20 > before those "in control" of the standards realize that there=20 > is a pressing need, indeed a requirement, among the users of=20 > the standard for true end-to-end security and put something=20 > that "they" think is OK in place to address it? >=20 > Faithfully submitted, > Dougla... *cough* >=20 > FM >=20 >=20 > On Tue, 2007-06-19 at 20:13 -0400, Jonathan Rosenberg wrote: > > This is part of why I think we need sips - we have countless drafts=20 > > which reference it as the security mechanism to use when=20 > you want to=20 > > protect against modification of signaling messages by=20 > off-path attackers. > >=20 > > Thus, I think this draft should continue the current policy and=20 > > reference sips. > >=20 > > Thanks, > > Jonathan R. > >=20 > > Kevin Johns wrote: > >=20 > > > Keith, > > >=20 > > > I have reviewed this document. The only question I have is its=20 > > > reference to SIPS as a way to mitigate some security risks. Given=20 > > > the status of SIPS I was unsure whether it should be listed as a=20 > > > mechanism for addressing possible security risks?=20 > Otherwise this document looks good. > > >=20 > > > Regards, > > > Kevin Johns > > >=20 > > > -----Original Message----- > > > From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > > Sent: Friday, April 13, 2007 9:42 AM > > > To: IETF SIP List > > > Subject: RE: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 > > >=20 > > > A reminder that you now have just one week to reply on this WGLC. > > >=20 > > > It would be nice to have some indication that people have even=20 > > > looked at this reasonably short document. > > >=20 > > > Remember, if we cannot get this document out of the door, then we=20 > > > cannot get ICE out of the door either. > > >=20 > > > Regards > > >=20 > > > Keith > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: Drage, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > >>Sent: Thursday, March 29, 2007 6:09 PM > > >>To: IETF SIP List > > >>Subject: [Sip] WGLC on draft-ietf-sip-ice-option-tag-01 > > >> > > >>(As WG chair) > > >> > > >>WGLC has just commenced in the MMUSIC WG on=20 > > >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt > > >> > > >>This is to announce a parallel WGLC on > > >>http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option- > > >>tag-01.txt > > >> > > >>The dates of the WGLC are identical to those in MMUSIC.=20 > > >>Therefore please provide responses to the WGLC by 20th April 2007. > > >> > > >>Comments on the SIP document should be provided to the SIP list=20 > > >>only, and to the editor. Please provide comments clearly=20 > indicating=20 > > >>the page > > >=20 > > >=20 > > >>or section, the text to be changed (copy and paste!), and the=20 > > >>proposed > > >=20 > > >=20 > > >>modification if possible. > > >> > > >>Regards > > >> > > >>Keith > > >> > > >>_______________________________________________ > > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >>This list is for NEW development of the core SIP Protocol Use=20 > > >>sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > >>sipping@ietf.org for new developments on the application of sip > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sipping@ietf.org for new developments on the application of sip > > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 12:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13VV-0007gS-Oz; Wed, 20 Jun 2007 12:58:13 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I13VU-0007gN-Az for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 12:58:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13VU-0007gF-1V for sip@ietf.org; Wed, 20 Jun 2007 12:58:12 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13VT-0006P7-JB for sip@ietf.org; Wed, 20 Jun 2007 12:58:12 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5KGux9E020313 for ; Wed, 20 Jun 2007 11:58:08 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:58:01 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 18:57:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] I-D Action:draft-ietf-sip-ice-option-tag-02.txt Date: Wed, 20 Jun 2007 18:57:59 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001303F5C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] I-D Action:draft-ietf-sip-ice-option-tag-02.txt Thread-Index: Acey05Qwc0j5cw6dRf6qOsn+gkGP3wAg71nw References: From: "DRAGE, Keith \(Keith\)" To: "IETF SIP List" Cc: X-OriginalArrivalTime: 20 Jun 2007 16:57:59.0509 (UTC) FILETIME=[2822F050:01C7B35C] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This version should address all the WGLC comments on this draft, and that should mean we are done with this draft. The related draft-ietf-mmusic-ice is currently undergoing a further WGLC, so we will wait until that is ready before submitting to IESG. That gives you a window to check that your comments and concerns already expressed have been addressed. Please check sooner rather than later. I would also suggest that we are at the stage where if you want text changed, it is more than appropriate to state exactly what you believe the new text should be, in order to prevent too many rounds of clarification on what is intended by the comment. Regards Keith > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Wednesday, June 20, 2007 1:40 AM > To: i-d-announce@ietf.org > Cc: sip@ietf.org > Subject: [Sip] I-D Action:draft-ietf-sip-ice-option-tag-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol=20 > Working Group of the IETF. >=20 > =20 > =20 > Title : Indicating Support for Interactive=20 > Connectivity Establishment (ICE) in the Session Initiation=20 > Protocol (SIP) > Author(s) : J. Rosenberg > Filename : draft-ietf-sip-ice-option-tag-02.txt > Pages : 8 > Date : 2007-06-19 > =20 > =20 > This specification defines a media feature tag and an option=20 > tag for use with the Session Initiation Protocol (SIP). The=20 > media feature tag allows a UA to communicate to its registrar=20 > that it supports ICE. > The option tag allows a User Agent (UA) to require support=20 > for ICE in order for a call to proceed. > =20 > =20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-ice-option- > tag-02.txt > =20 > =20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > =20 > =20 > =20 > =20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then > "get draft-ietf-sip-ice-option-tag-02.txt". > =20 > =20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > =20 > =20 > =20 > =20 > Internet-Drafts can also be obtained by e-mail. > =20 > =20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-ice-option-tag-02.txt". > =20 > =20 > 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=20 > "munpack" or > a MIME-compliant mail reader. Different=20 > MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have=20 > been split > up into multiple messages), so check your local=20 > documentation on > how to manipulate these messages. > =20 > =20 > =20 > =20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. > =20 > =20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 13:13:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13jp-0002Be-B8; Wed, 20 Jun 2007 13:13:01 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzMfO-0003Cx-Ry for sip-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 21:01:26 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1HzMfO-0003Cp-Io for sip@ietf.org; Fri, 15 Jun 2007 21:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFPb-0006gD-4O for sip@ietf.org; Fri, 15 Jun 2007 13:16:39 -0400 Received: from m13-81.163.com ([220.181.13.81]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzFPZ-0000C2-DO for sip@ietf.org; Fri, 15 Jun 2007 13:16:39 -0400 Received: from 192.168.208.60 ( 192.168.208.60 [192.168.208.60] ) by ajax-webmail-wmsvr81 (Coremail) ; Sat, 16 Jun 2007 01:16:28 +0800 (CST) Date: Sat, 16 Jun 2007 01:16:28 +0800 (CST) From: yan To: sip@ietf.org Message-ID: <26704133.554821181927788647.JavaMail.coremail@bj163app81.163.com> MIME-Version: 1.0 X-Originating-IP: [192.168.208.60] X-Priority: 3 X-Mailer: Coremail Webmail Server Version 3.1.0 build 070614(3445.1114.1103) Copyright (c) 2002-2007 www.mailtech.cn 163com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-TMDA-Confirmed: Fri, 15 Jun 2007 21:01:26 -0400 X-Mailman-Approved-At: Wed, 20 Jun 2007 13:12:59 -0400 Subject: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFY transaction has completed? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176497313==" Errors-To: sip-bounces@ietf.org --===============0176497313== Content-Type: multipart/Alternative; boundary="----=_Part_60511_31312004.1181927788646" ------=_Part_60511_31312004.1181927788646 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit hi: Could anyone answer me the question:Can a UA issue a new NOTIFY before the previous NOTIFY transaction has completed? thx yan ------=_Part_60511_31312004.1181927788646 Content-Type: text/html; charset=gbk Content-Transfer-Encoding: quoted-printable
hi:
  Could anyone answer me the question:
Can a UA issue a new NOTIFY before the previous NOTIFY transaction has= completed?
 thx
 
yan


150 =CD= =F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 =D3=CE=A3=AC=C4=E3 =B2= =BB =CA=D4 =CA=D4 =C2=F0 =A3=BF ------=_Part_60511_31312004.1181927788646-- --===============0176497313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0176497313==-- From sip-bounces@ietf.org Wed Jun 20 13:18:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13oz-0005hF-Ek; Wed, 20 Jun 2007 13:18:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I13ox-0005h5-Sd for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 13:18:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13ox-0005gx-I0 for sip@ietf.org; Wed, 20 Jun 2007 13:18:19 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I13ov-0000Qm-4L for sip@ietf.org; Wed, 20 Jun 2007 13:18:19 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l5KHI892064971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Jun 2007 12:18:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <26704133.554821181927788647.JavaMail.coremail@bj163app81.163.com> References: <26704133.554821181927788647.JavaMail.coremail@bj163app81.163.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: <72E9168E-F9BD-4E1A-941C-23B13AC95DE3@nostrum.com> From: Robert Sparks Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFY transaction has completed? Date: Wed, 20 Jun 2007 12:18:07 -0500 To: yan X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664698760==" Errors-To: sip-bounces@ietf.org --===============0664698760== Content-Type: multipart/alternative; boundary=Apple-Mail-15-41741396 --Apple-Mail-15-41741396 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Generally speaking, yes. An individual event package may restrict that behavior though. RjS On Jun 15, 2007, at 12:16 PM, yan wrote: > hi: > Could anyone answer me the question: > Can a UA issue a new NOTIFY before the previous NOTIFY transaction =20 > has completed? > thx > > yan > > > 150 =E4=B8=87 =E4=BA=BA =E5=90=8C =E6=97=B6 =E5=9C=A8 =E7=8E=A9 =E7=9A=84= =E7=BD=91 =E6=B8=B8=EF=BC=8C=E4=BD=A0 =E4=B8=8D =E8=AF=95 =E8=AF=95 =E5=90= =97 =EF=BC=9F > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --Apple-Mail-15-41741396 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Generally speaking, yes.

An individual event package = may restrict that behavior though.

RjS

O= n Jun 15, 2007, at 12:16 PM, yan wrote:

hi:
=C2=A0 Could anyone answer me the = question:
Can a UA issue a new NOTIFY before the previous = NOTIFY transaction has completed?
=C2=A0thx
=
=C2=A0
yan


150 =E4=B8=87 =E4=BA=BA =E5=90=8C =E6=97=B6 =E5=9C=A8 =E7=8E=A9= =E7=9A=84 =E7=BD=91 =E6=B8=B8=EF=BC=8C=E4=BD=A0 =E4=B8=8D =E8=AF=95 =E8=AF= =95 =E5=90=97 =EF=BC=9F
This list is = for NEW development of the core SIP Protocol
Use sip-implementors@cs.colum= bia.edu for questions on current sip
Use sipping@ietf.org for new = developments on the application of sip
=

= --Apple-Mail-15-41741396-- --===============0664698760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0664698760==-- From sip-bounces@ietf.org Wed Jun 20 15:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15w2-0002zz-1d; Wed, 20 Jun 2007 15:33:46 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I15w0-0002zk-OM for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15w0-0002zX-ED for sip@ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15vz-0003Z5-NZ for sip@ietf.org; Wed, 20 Jun 2007 15:33:44 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1DCB42048D; Wed, 20 Jun 2007 21:33:43 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-96-46798117caee Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 01417203E7; Wed, 20 Jun 2007 21:33:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:33:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] INFO usage (or not) Date: Wed, 20 Jun 2007 21:33:40 +0200 Message-ID: <7374777208BDC7449D5620EF9423256705D1372B@esealmw113.eemea.ericsson.se> In-Reply-To: <467867F9.2030501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] INFO usage (or not) Thread-Index: AceyymLAZVrVnHhpSFaZ9riuWT+3twAoVVSA References: <5D1A7985295922448D5550C94DE29180012C969F@DEEXC1U01.de.lucent.com> <7374777208BDC7449D5620EF94232567056C1E21@esealmw113.eemea.ericsson.se> <467867F9.2030501@cisco.com> From: "Christer Holmberg (JO/LMF)" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 20 Jun 2007 19:33:42.0616 (UTC) FILETIME=[E90FED80:01C7B371] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: IETF SIP List , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi,=20 >>I am also confused that people seem to think that INFOs will start=20 >>flying around for no reason, without the sender having any=20 >>clue about whether the receiver will understand them or not. As we have=20 >>discussed, there ARE mechanisms in SIP to negotiate what content types >>etc entities support. Yes, MAYBE we need to extend that (e.g. >>being able to indicate which methods can be used to carry a=20 >>specific content type), if what we have is not enough. But, to me=20 >>that is not the same thing has having "tons of problem". >=20 >There is a big difference between, "I can support this=20 >format", and "I am interested in having you send me events in=20 >this format".=20 When you indicate the stuff you support in an OPTIONS response, I agree it's "I can support this format". But, if I in an INVITE response indicate support of a certain content type I think that can also be seen as "When/if you are going to send me X, please use this format". >This is why we didn't go with the INFO method for DTMF. Since DTMF would already be arriving at the UAS in=20 >the form of 2833, the primary entities needing signaling-based solutions are applications not on the media=20 >path. In most cases, yes, and my intention is not to promote people to use a signaling-based solution instead of 2833. We could even make very strong recommendations to always use 2833, when possible. (However, in theory you could also have a signalling gateway, without access to media, which sends the DTMFs using a signaling-based solution since the protocol "on the other side" also does it.) >But, we only want to send such signaling when there is an application that is interested. This is exactly what=20 >SUB/NOT is for - to ask for notifications of events. The application may not necessarily know that I am going to send him anything, and then it will have to ask "just in case". =20 >Furthermore, by using a separate dialog we could have the=20 >notifications sent just to the interested application server,=20 >so that the proxies on the path of the original dialog don't=20 >need to see INFO messages flying by if they weren't interested. That is an advantage, yes. ...eventhough I wonder how many proxies you actually would be able to "skip" in real life scenarios. You may have routes established using Path and/or Service-Route, for example. >Consider further the other UA in the call. If it supports=20 >both DTMF-over-INFO and RFC2833, what does it mean to get=20 >both? If you generate DTMF on receipt of INFO, you stand a=20 >real risk of generating double DTMF which is very bad. You have exactly the same problem with SUB/NOT, if you BOTH subscribbe to the DTMF event AND inciate support of 2833 in your SDP. So, the solution is: you indicate EITHER support of 2833 OR the signaling-based mechanism (whatever it is).=20 >You avoid this problem if you only send DTMF over signaling when asked; this way the thing getting the rfc2833 doesn't=20 >ask for it. I am not sure I understand that. Even if I use SUB/NOT I don't know exactly when the DTMF event will come (if it will come), and I could still also receive 2833 while the subscription is active. >Using SUB/NOT also allowed the application to customize when it would get a notification. So for example an app that=20 >needed each digit as it was pressed could get them immediately. One only needing them after some >pattern was matched could only get it then. This was also a perfect match for SUB/NOT. Well, obviously people using INFO do not need the subscriber to be able to "push" the digitmap. But, if I am asked to give 4 digits I may implement a user interface which allows me to enter the digits before they are sent in a single INFO (assuming the INFO based mechanism allows it). >So there are serious technical limitations to carrying DTMF=20 >over INFO.=20 >Sure, it can 'work', but it is very suboptimal and can cause problems. >=20 >As for a general INFO usage, my opinion is unchanged on this.=20 >We have numerous methods for extending SIP by adding new=20 >headers and methods and event packages. Can you demonstrate a=20 >use case where one of these extensibility mechanisms is not=20 >sufficient for some use case? >From a functional perspective I am pretty sure they are sufficient. And, I am not saying that all INFO usages are good, and that you couldn't use a better (both from a functionality and complexity perspective) alternative. Regards, Christer _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 20:29:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYR-0007hg-QR; Wed, 20 Jun 2007 20:29:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1AYQ-0007hY-OM for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 20:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYQ-0007hQ-EV; Wed, 20 Jun 2007 20:29:42 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1AYP-0002d6-5C; Wed, 20 Jun 2007 20:29:42 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 08838D6BB0; Wed, 20 Jun 2007 17:28:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070621002824.08838D6BB0@bosco.isi.edu> Date: Wed, 20 Jun 2007 17:28:24 -0700 (PDT) X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4916 on Connected Identity in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4916 Title: Connected Identity in the Session Initiation Protocol (SIP) Author: J. Elwell Status: Standards Track Date: June 2007 Mailbox: john.elwell@siemens.com Pages: 24 Characters: 42924 Updates: RFC3261 See-Also: I-D Tag: draft-ietf-sip-connected-identity-05.txt URL: http://www.rfc-editor.org/rfc/rfc4916.txt This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 20 23:44:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Daz-0006Hs-Gs; Wed, 20 Jun 2007 23:44:33 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Day-0006Hn-CC for sip-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 23:44:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Day-0006He-2W for sip@ietf.org; Wed, 20 Jun 2007 23:44:32 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Dax-0002Lx-Mz for sip@ietf.org; Wed, 20 Jun 2007 23:44:32 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I1Daw-0003Gv-3T; Wed, 20 Jun 2007 23:44:31 -0400 Message-ID: <4679F41A.4020805@bbn.com> Date: Wed, 20 Jun 2007 23:44:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [Sip] SIP SAML Review by Richard Barnes X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Draft: draft-ietf-sip-saml-02 Reviewer: Richard Barnes Review Date: 18 Jun 07 Security / Privacy Concerns: ------------------------------------------------------------------------ 1. It's never made clear what entity is the Subject of the conveyed assertions. This could be a critical distinction, e.g., if one party assumes that it's the UAC being discussed, and the other the user of the UAC. 2. Section 9 needs a discussion the nature of the assurances provided by SAML assertions. In general, in order for it to be verifiable that the SAML assertion was issued by the Authentication Service, there must be proof that the holder of the private key used to create the Identity-Info header. There are several ways to do this: 2.a. The SAML assertion is signed with the appropriate private key 2.b. An unsigned SAML assertion is provided over HTTPS by a server that authenticates with the same certificate 2.c. The Identity-Info is integrity-protected from the point where it is added by the Authentication Service until it reaches the UAS. 3. The list of threats and countermeasures in Section 9 is incomplete. For instance: 3.a. There's no discussion of threats of attacks by elements of the SIP signaling path (e.g., manipulating the URI in the Identity-Info header) 3.b. The anti-replay mechanism should reference the expiry elements built into the assertion (e.g., the NotOnOrAfter attribute) 4. The document isn't clear on whether or not the assertions MUST be signed by the issuer. Section 6.1.5, step 3 seems to imply that the assertion will be signed, but Section 9.3 seems to assume that this isn't necessarily the case. IMHO, it should be that the assertion MUST be signed by the same key used to generate the identity digest. But even if this isn't the case, this point should be clarified. 5. No mention is made of the possible sensitivity of the contents of SAML assertions. It's possible that these assertions could contain sensitive information about the Subject, such as statements about what identities the subject holds. There should be some discussion about what measures should be taken in this case, e.g., the use of HTTPS and authentication of dereferencing clients. General Comments: ------------------------------------------------------------------------ 1. Conveying SAML assertions via a URI in the Identity-Info header contradicts Section 9 of RFC 4474, which says that the resource indicated MUST be of type "application/pkix-cert". ISTM there are at least a couple of ways to fix this: 1.a. Normatively update RFC 4474 to allow the resource to be of either type 1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with one part of each type 1.c. Add a separate header to carry the SAML assertion In the interest of backward-compatibility, I don't think you can get rid of application/pkix-cert altogether. 2. The subdivisions under sections 6 and 7 seem unnecessary. Section 6.1.X should be Section 6.X (or maybe 6.(X+1)), and likewise for section 7. Localized Comments and Nits: ------------------------------------------------------------------------ Section 2: I would switch the order of the definitiosn of "profile attribute(s)" and "user profile, subject profile". Section 3, paragraph starting "Thus one can employ...": Change "to make and encode statements" to "to encode statements". Section 6.1.2, paragraph starting "Although this...": Change "this profile is overview is" to "this profile overview is" Figure 2: In the INVITE messages, the AoR in the From: header should be "sip:alice@foo.com" Section 6.1.2, Step 3: The AS is supposed to insert "attributes required by Bob's domain". How is it supposed to know which attributes these are? This is answered by the following paragraph, which should be moved up to here. Section 6.1.2, Step 3: The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be a reference according to the binding defined in this document, instead of the original (SAMLv2) reference standard? Section 6.1.2, Step 5, second paragraph: "the AS continues" should be "the UAS continues" Section 6.1.3.3, third paragraph: This paragraph gives the option of HTTPS or HTTP, but doesn't specify that one of the two MUST be used. Suggested text: "The AS MUST construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. It is RECOMMENDED that the AS construct an HTTPS URI." Section 6.1.3.3, fourth paragraph: This is not technically correct; the URI should be the absoluteURI portion of the Identity-Info header value. Section 6.1.4: Through out this section, situations with exceptions are presented as "SHOULD ... MAY ...". As I read it, this creates a situation without a mandatory default behavior; I would prefer if these were worded as MUSTs, with MAYs allowed under specified circumstances. Section 6.1.4.1.3: The SHOULDs in this section should be should be MUSTs. Section 6.1.4.1.4, second paragraph: This needs to say that the attribute-value pairs MUST pertain to the subject of the assertion (a concept which needs to be tied to a SIP entity elsewhere in the document). This may be the entity identified in the From header, or another identified entity. Section 6.1.5, Step 3: Section 5.4 of the indicated reference doesn't say anything about how signatures are verified. Instead, this should reference Section 3.2 of the XMLdsig document referenced. Also is this TODO resolved? Section 6.1.5, Step 5: Specify how this verification is done, e.g., by verifying that the signed-identity-digest and the signature on the SAML assertion are both verifiable with the key in the cert in the assertion. Section 6.1.5, Step 7: The relevant field in the X.509 certificate are Subject and Subject Alternative Name (not Issuer and Issuer Alternative Name). The Issuer of the assertion is the Subject of the certificate. Section 7: This binding doesn't really have anything to do with SIP. Could we just exclude SIP from the name? Maybe this could be the IETF standard URI binding of SAML. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 06:20:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jm2-0003lb-Ih; Thu, 21 Jun 2007 06:20:22 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Jm0-0003lT-Fk for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 06:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Jlz-0003lL-No for sip@ietf.org; Thu, 21 Jun 2007 06:20:19 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Jlx-000545-Ku for sip@ietf.org; Thu, 21 Jun 2007 06:20:19 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJZ003TCE0HL3@szxga04-in.huawei.com> for sip@ietf.org; Thu, 21 Jun 2007 18:19:29 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJZ009LHE0HWC@szxga04-in.huawei.com> for sip@ietf.org; Thu, 21 Jun 2007 18:19:29 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJZ00IWME0CLR@szxml03-in.huawei.com> for sip@ietf.org; Thu, 21 Jun 2007 18:19:29 +0800 (CST) Date: Thu, 21 Jun 2007 18:19:24 +0800 From: Qian Sun To: Gonzalo.Camarillo@ericsson.com Message-id: <000e01c7b3ed$a3fe46c0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Acez7aOtdN64rmfyRQazzRNqkgEz5Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'IETF SIP List' Subject: [Sip] Comments on draft-camarillo-sip-body-handling-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, In section 4.3, there is the following text: "(e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response." Can I include a Content-ID URL like this? Refer-To: And the Content-ID URL point to a body part, whose disposition type is not ' recipient-list', might be 'session'. Maybe this draft could write something about the special hname "body", since the purpose of the draft is to clarify how message bodies are handled in SIP. Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 08:52:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1M96-0006zv-CI; Thu, 21 Jun 2007 08:52:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1M94-0006wz-TS for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 08:52:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1M94-0006wq-Jt for sip@ietf.org; Thu, 21 Jun 2007 08:52:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1M94-0000LE-81 for sip@ietf.org; Thu, 21 Jun 2007 08:52:18 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 08:52:16 -0400 X-IronPort-AV: i="4.16,447,1175486400"; d="scan'208"; a="63337709:sNHT144307170" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5LCqFSP005151; Thu, 21 Jun 2007 08:52:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LCq6Lj007635; Thu, 21 Jun 2007 12:52:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:52:10 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:52:09 -0400 Message-ID: <467A7478.7030405@cisco.com> Date: Thu, 21 Jun 2007 08:52:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 References: <000e01c7b3ed$a3fe46c0$7c6c460a@china.huawei.com> In-Reply-To: <000e01c7b3ed$a3fe46c0$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2007 12:52:09.0776 (UTC) FILETIME=[FB060B00:01C7B402] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1619; t=1182430335; x=1183294335; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-camarillo-sip-body-hand ling-01 |Sender:=20 |To:=20Qian=20Sun=20; bh=slf2fcyObFzRAsaK9ZE8VW0iHUsM3bFS3QoXgvWQlmY=; b=ZUNfe8mwlguaoxfag2IU/oDsBCL6fJf3zknDISS+j5KgPTKbzIAyet7CXka0fQx1Mf6zHvVI 6XAvLvZxYPglc9UAYwj1pfNPYeg1zw/K1TAVajCmKO2TWkxSmsGiIIbM; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'IETF SIP List' , Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Qian Sun wrote: > Hello, > > In section 4.3, there is the following text: > "(e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response." > > Can I include a Content-ID URL like this? > Refer-To: > And the Content-ID URL point to a body part, whose disposition type is not ' recipient-list', might be 'session'. The construction seems to be nonsense. When the REFER containing this is acted upon it would result in an INVITE with a body containing the CID URI. I assume you want the resulting INVITE to have the referenced body part as its body. That sounds possibly useful, but I don't see any way to disambiguate the cases. The use of "body" as a SIP URI parameter is interesting for completeness with header parameters, but I have never seen a use of it. The use of header parameters in general is pretty limited. > Maybe this draft could write something about the special hname "body", since the purpose of the draft is to clarify how message bodies are handled in SIP. It seems off-topic to what the draft is otherwise tackling. Paul > Cheers, > Qian > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 10:29:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Nf5-00031A-Rx; Thu, 21 Jun 2007 10:29:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Nf3-000313-J7 for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 10:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Nf3-00030v-9Z for sip@ietf.org; Thu, 21 Jun 2007 10:29:25 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Nf1-0001FX-Kc for sip@ietf.org; Thu, 21 Jun 2007 10:29:25 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l5LETJD0021429; Thu, 21 Jun 2007 16:29:21 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5LETGYO015977; Thu, 21 Jun 2007 16:29:19 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 16:29:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jun 2007 16:28:41 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A407580218A42E@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP SAML Comments by Mayutan Arumaithurai Thread-Index: AcezDt0a82E5QL1ySbi+hgSH7wosLgBAWNSQ From: "Tschofenig, Hannes" To: "SIP IETF" X-OriginalArrivalTime: 21 Jun 2007 14:29:17.0075 (UTC) FILETIME=[8C5D4E30:01C7B410] X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: mayutan.arumaithurai@gmail.com Subject: [Sip] SIP SAML Comments by Mayutan Arumaithurai X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1535786482==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1535786482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B410.7864AAE4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B410.7864AAE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is another review.=20 =20 ________________________________ Von: ext Mayutan A. [mailto:mayutan.arumaithurai@gmail.com]=20 Gesendet: Mittwoch, 20. Juni 2007 09:45 An: Tschofenig, Hannes Betreff: Re: SIP SAML Comments HI Hannes ,=20 I do not have any major comments on the SIP SAML draft.=20 My comments are limited to spelling mistakes.=20 Section 5 , sentence 1=20 "Because the those " is wrong. suggestion remove "the" section 6.1.2 , 2nd para , first sentence=20 "Although this profile is overview" ... suggestion "profile's " section 6.1.3 , 3rd sentence ,=20 separate is spelt wrong section 6.3.1.1 , 3rd sentence "The particulars of how this is accomplished depend upon implementation.." sounds wrong .. suggestion "dependS upon THE"=20 section 6.3.1.2 , last line proceeds is spelt wrongly section 6.3.1.3 , first line Makes more sense if the first line begins with THE 6.1.3.4 , 2nd sentence It has "the the"=20 6.1.4.1, attribute ID requirement is spelt wrong section 7.1, 3rd para this profile of the SAML URI Binding is congruent with the SAML URI binding ---- does not make sense Mayutan ------_=_NextPart_001_01C7B410.7864AAE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Here is another review.
 
Von: ext Mayutan A.=20 [mailto:mayutan.arumaithurai@gmail.com]
Gesendet: Mittwoch, = 20. Juni=20 2007 09:45
An: Tschofenig, Hannes
Betreff: Re: SIP = SAML=20 Comments

HI Hannes ,

I do not have any major comments on the = SIP=20 SAML  draft.
My comments are limited to spelling mistakes.=20

Section 5 , sentence 1
"Because the those " is wrong. = suggestion=20 remove "the"

section 6.1.2 , 2nd para , first sentence =
"Although this=20 profile is overview" ... suggestion "profile's "

section 6.1.3 , = 3rd=20 sentence  ,
separate is spelt wrong

section 6.3.1.1 , 3rd sentence
"The particulars = of how this=20 is accomplished depend upon implementation.." sounds wrong .. suggestion = "dependS upon THE"

section 6.3.1.2 , last=20 line
proceeds is spelt wrongly

section 6.3.1.3 , first line
Makes more sense if = the first=20 line begins with THE

6.1.3.4 = ,  2nd=20 sentence
It has "the the"

6.1.4.1,=20 attribute ID
requirement is spelt wrong

section 7.1, 3rd parathis = profile of the=20 SAML URI Binding is congruent with the SAML URI binding ---- does not = make=20 sense

Mayutan

------_=_NextPart_001_01C7B410.7864AAE4-- --===============1535786482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1535786482==-- From sip-bounces@ietf.org Thu Jun 21 10:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Nwy-0000sV-QR; Thu, 21 Jun 2007 10:47:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Nwx-0000sA-5u for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 10:47:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Nww-0000s1-Q8 for sip@ietf.org; Thu, 21 Jun 2007 10:47:54 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Nwu-0000KD-Rw for sip@ietf.org; Thu, 21 Jun 2007 10:47:54 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l5LElo2l019749 for ; Thu, 21 Jun 2007 16:47:50 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5LElquW001109 for ; Thu, 21 Jun 2007 16:47:52 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 16:47:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jun 2007 16:47:46 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B017C1FD0@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments draft-ietf-sip-saml-02 Thread-Index: Ace0EyGGrqpYQWMDTfKT4PMWDA0xfw== From: "Willekens, Marc" To: X-OriginalArrivalTime: 21 Jun 2007 14:47:50.0909 (UTC) FILETIME=[2442E2D0:01C7B413] X-Spam-Score: 0.0 (/) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Subject: [Sip] Comments draft-ietf-sip-saml-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053718937==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1053718937== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B413.23E31526" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B413.23E31526 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, here are some comments to the draft: = http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt =20 a) Comments [Page 2], Abstract Can you add a reference to the corresponding RFC number? (RFC4474, = RFC4484?) =20 [Page 3], Introduction Is this document only about assertion for the authorization or also for = the authentication? =20 [Page 7], 3.1. SAML Assertion ...including issuer, timestamp (IssueInstant) and subject ... =20 [Page 9], 4. Specification scope ...SIP profile and binding ... =20 [Page 12] Domain name for Alice: example.com or foo.com?? (same comment for other = figures) Authentication service or Assertion service or both? =20 [Page 13], 6.1. Assertion Fetch profile Is this the only planned profile or will other profiles be defined and = added later? Will there also be a push based model? Will it then be = "pushed" as part of the SIP message?=20 =20 [Page 13], 6.1.1. URN What's the current consensus for the urn? =20 [Page 17], 6.1.3. ...sender and Authentication service (AS) may be separate or... ??? How will the AS and sender be combined? Should it not be Authentication = or Assertion service which can be combined? =20 [Page 22], 6.1.4.1.4. AttributeStatement is indicated. But what about Authentication and = Authorization Decision statement?=20 =20 [Page 23], Step 3, TODO I think it's always good to indicate problems with the assertion. =20 [Page36], Figure 5 should de saml: keyword not be added for the XML elements? saml:Assertion,=20 =20 [Page30] Security considerations Is it possible to redirect messages to an own authentication service by = manipulating the end-device? How can the called party trust the = authentication service assigned by the caller? =20 [Page31] This RFC draft talks about assertions. But how can an identity be = asserted only by considering a device, e.g. in case a device is stolen = or temporary used by someone else? At VON 2000, H. Schulzrinne has = already indicated that something as fingerprint has to be added for a = device with a changing set of owners.=20 =20 =20 b) Typos [Page 11], 5, =A71: ...because the those -> because those:=20 [Page 14], 5.1.2: ...Although this profile is overview ....->=20 [Page 21], 5.1.4.1: ....requirments .... ->=20 [Page 40], Appendix A: ...addtional. ->=20 =20 br, Marc. ------_=_NextPart_001_01C7B413.23E31526 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, here are some comments to the draft: = h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt<= /B>

 

a) = Comments

[Page = 2],=20 Abstract

Can = you add a=20 reference to the corresponding RFC number? (RFC4474, = RFC4484?)

 

[Page = 3],=20 Introduction

Is = this document=20 only about assertion for the authorization or also for the=20 authentication?

 

[Page = 7], 3.1. SAML=20 Assertion

...including issuer,=20 timestamp (IssueInstant) and subject ...

 

[Page = 9], 4.=20 Specification scope

...SIP = profile and=20 binding ...

 

[Page = 12]

Domain = name for=20 Alice:=20 example.com or foo.com?? (same comment for other figures)

Authentication=20 service or Assertion service or both?

 

[Page = 13], 6.1.=20 Assertion Fetch profile

Is = this the only=20 planned profile or will other profiles be defined and added later?  Will there also be a push = based model?=20 Will it then be "pushed" as part of the SIP message?

 

[Page = 13], 6.1.1.=20 URN

What's = the current=20 consensus for the urn?

 

[Page = 17],=20 6.1.3.

...sender and=20 Authentication service (AS) may be separate or... ???

How = will the AS and=20 sender be combined? Should it not be Authentication or Assertion service = which=20 can be combined?

 

[Page = 22],=20 6.1.4.1.4.

AttributeStatement=20 is indicated. But what about Authentication and Authorization Decision=20 statement?

 

[Page = 23], Step 3,=20 TODO

I = think it's always=20 good to indicate problems with the assertion.

 

[Page36], Figure=20 5

should = de saml:=20 keyword not be added for the XML elements?

saml:Assertion,=20

 

[Page30] Security=20 considerations

Is it = possible to=20 redirect messages to an own authentication service by manipulating the=20 end-device? How can the called party trust the authentication service = assigned=20 by the caller?

 

[Page31]

This = RFC draft talks=20 about assertions. But how can an identity be asserted only by = considering a=20 device, e.g. in case a device is stolen or temporary used by someone = else? At=20 VON 2000, H. Schulzrinne has already indicated that something as = fingerprint has=20 to be added for a device with a changing set of owners.

 

 

b)=20 Typos

[Page = 11], 5, =A71:=20 ...because the those -> because those:

[Page = 14], 5.1.2:=20 ...Although this profile is overview ....->

[Page 21], 5.1.4.1: = ....requirments=20 .... ->

[Page 40], Appendix A: = ...addtional.=20 ->

 

br,

Marc.

------_=_NextPart_001_01C7B413.23E31526-- --===============1053718937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1053718937==-- From sip-bounces@ietf.org Thu Jun 21 11:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Olz-0003bi-C7; Thu, 21 Jun 2007 11:40:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Olv-0003ZG-2l for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Olu-0003Z5-P2 for sip@ietf.org; Thu, 21 Jun 2007 11:40:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Ols-00007s-Vl for sip@ietf.org; Thu, 21 Jun 2007 11:40:34 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2007 08:40:32 -0700 X-IronPort-AV: i="4.16,448,1175497200"; d="scan'208,217"; a="4215407:sNHT60528372" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5LFeWRg004312; Thu, 21 Jun 2007 08:40:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l5LFeWvv023550; Thu, 21 Jun 2007 15:40:32 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:40:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFYtransaction has completed? Date: Thu, 21 Jun 2007 08:37:52 -0700 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <72E9168E-F9BD-4E1A-941C-23B13AC95DE3@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFYtransaction has completed? Thread-Index: AcezXwZ4j3b+jY7uS7e1+uQ/OfLd1wAuumsQ From: "Arunachalam Venkatraman \(arunvenk\)" To: "Robert Sparks" , "yan" X-OriginalArrivalTime: 21 Jun 2007 15:40:31.0857 (UTC) FILETIME=[80554610:01C7B41A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12246; t=1182440432; x=1183304432; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=arunvenk@cisco.com; z=From:=20=22Arunachalam=20Venkatraman=20\(arunvenk\)=22=20 |Subject:=20RE=3A=20[Sip]=20Could=20a=20UA=20issue=20a=20new=20NOTIFY=20b efore=20the=20previous=20NOTIFYtransaction=20has=20completed? |Sender:=20; bh=tpCH+hKqDVxW9vM39UJfKxjbswiTHOHqI5pdFDVctOA=; b=Dn/wJgq7jSDqxUqRSCOcmOh9B7R/yD53tgkWzQ/PKCT+1NjWRmg5t48yxor1kubtpoFjQxqk R/kE6IUPEPpvhYQ4MxqqB1DyWs/mEPs6ighXwvcJ/sYKCnjxtk+skpRc; Authentication-Results: sj-dkim-4; header.From=arunvenk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1214237482==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1214237482== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B41A.80210427" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B41A.80210427 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable However, if you are using UDP and if the data in the second NOTIFY is = additive to and not replacing the prior NOTIFY, you may run into the = issue of out-of-sequence delivery. =20 =20 ________________________________ From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: Wednesday, June 20, 2007 12:18 PM To: yan Cc: sip@ietf.org Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous = NOTIFYtransaction has completed? =20 Generally speaking, yes. =20 An individual event package may restrict that behavior though. =20 RjS =20 On Jun 15, 2007, at 12:16 PM, yan wrote: hi: Could anyone answer me the question:=20 Can a UA issue a new NOTIFY before the previous NOTIFY transaction has = completed? thx =20 yan =20 ________________________________ 150 =CD=F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 = =D3=CE=A3=AC=C4=E3 =B2=BB =CA=D4 =CA=D4 =C2=F0 =A3=BF = =20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip =20 ------_=_NextPart_001_01C7B41A.80210427 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

However, if you are using UDP and = if the data in the second NOTIFY is additive to and not replacing the prior = NOTIFY, you may run into the issue of out-of-sequence = delivery.

 

 

From: = Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: Wednesday, June 20, = 2007 12:18 PM
To: yan
Cc: sip@ietf.org
Subject: Re: [Sip] Could = a UA issue a new NOTIFY before the previous NOTIFYtransaction has = completed?

 

Generally speaking, yes.

 

An individual event package may restrict that behavior = though.

 

RjS

 

On Jun 15, 2007, at 12:16 PM, yan = wrote:



hi:

  Could anyone answer me the question: =

Can a UA issue a new NOTIFY before the previous NOTIFY = transaction has completed?

 thx

 

yan

 

150 = =CD=F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 =D3=CE=A3=AC=C4=E3 =B2=BB =CA=D4 =CA=D4 =C2=F0 =A3=BF =

_______________________________________________=

This list is for NEW development of the core SIP = Protocol

Use sip-implementors@cs.colu= mbia.edu for questions on current sip

Use sipping@ietf.org for = new developments on the application of sip

 

------_=_NextPart_001_01C7B41A.80210427-- --===============1214237482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1214237482==-- From sip-bounces@ietf.org Thu Jun 21 11:41:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1On1-0006Ov-CQ; Thu, 21 Jun 2007 11:41:43 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Omz-0006FG-9r for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 11:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Omy-0006C4-V1 for sip@ietf.org; Thu, 21 Jun 2007 11:41:40 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Omx-0000I7-EP for sip@ietf.org; Thu, 21 Jun 2007 11:41:40 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5LFfaBb019286 for ; Thu, 21 Jun 2007 10:41:36 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5LFfZa21179; Thu, 21 Jun 2007 10:41:35 -0500 (CDT) Message-ID: <467A9C2F.6070209@alcatel-lucent.com> Date: Thu, 21 Jun 2007 10:41:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: SIP LIST X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Keith: Please see inline. DRAGE, Keith (Keith) wrote: > (As WG chair) > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 > .txt > > Describes a set of requirements for: [...] > (Before we go any further, please forget all about the solutions > document - that comes later and we are not dealing with it now) > > We need to decide whether there is support for a body of work in this > area, and therefore whether we should charter some requirements work in > the SIP WG. > > (Because this is security related we have agreed that SIP does the > requirements drafting and not SIPPING) > > So can I hear opinions of the WG on: > > - whether this represents a problem space that the working group > should draft requirements on? I must confess that on an initial reading of the draft, I was lost on the need for requirements that add certificate authentication to SIP. Using TLS, a registrar and a UAC and exchange certificates today and authenticate each other, without resorting to a shared secret, right? I beleive the use case that the author is going for has to do with using the hop-by-hop signaling path through a SIP proxy mesh to a registrar, but being able to exchange certificates directly between the UAC and the registrar. As such, the title of the draft ought to be reflective of this; something along the lines of "Requirements for direct registrar authentication in the Session Initiation Protocol (SIP) by a User Agent Client (UAC)". > - whether the problem space exists but is something slightly > different, and if so what is that problem space? If the problem space is defined as coming up with requirements for direct registrar authentication in SIP by a UAC over a normal SIP proxy mesh, then that is a reasonable problem space, IMHO. > - whether there is a more general problem that the security area > should be addressing, rather than the SIP group addressing something > specific? I beleive that this is fairly specific to SIP, but will defer to the chairs and the rest of the WG. > - based on your answers to the first three questions, whether this > draft is essentially in the right direction to be adopted as the WG > draft assuming we create the charter item, or whether we need to seek > some other input draft? This draft also talks about interpreting the contents of the certificates (S3, requirement 8). As such, some of the work Scott Lawrence and I have done in domain-certs provides more guidelines on this particular aspect. We received good feedback from the pkix WG in Prague when we presented domain-certs there; we are in the process of revising the domain-certs draft to include a discrete set of steps that can be programmed to do certificate validation. We should be sending a revised version of this draft out by tomorrow. > - and finally, whether (assuming we go ahead with this work) there > is any work in any other IETF WG that we should take account of? domain-certs, as mentioned above. In addition, sip-sipsec could provide a possible solution set; it appears to fit some of the requirements. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 12:52:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PtW-0006va-Tl; Thu, 21 Jun 2007 12:52:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1PtW-0006vV-33 for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 12:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1PtV-0006vN-Pm for sip@ietf.org; Thu, 21 Jun 2007 12:52:29 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1PtV-0004OQ-6u for sip@ietf.org; Thu, 21 Jun 2007 12:52:29 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l5LGqMp19615; Thu, 21 Jun 2007 09:52:22 -0700 In-Reply-To: <20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi> References: <20070419175200.g160v60gbo88kk4s@horde-intra.tml.hut.fi><9AAEDF491EF7CA48AB587781B8F5D7C6045F8F@srvxchg3.cablelabs.com> <20070420175922.xfff9li17kg4gkc8@horde-intra.tml.hut.fi> <9AAEDF491EF7CA48AB587781B8F5D7C6045FF4@srvxchg3.cablelabs.com> <20070427153610.2cd2cpls4ggwg0ks@horde-intra.tml.hut.fi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D18DA84-22CF-4976-B199-31ED975610B3@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Sip] outbound08 - Handling Responses in Edge proxy / Viavs.Flowtoken Date: Thu, 21 Jun 2007 09:52:20 -0700 To: sergiole@tml.hut.fi X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: sip@ietf.org, Rohan Mahy , Kevin Johns , Cullen Jennings X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Sergio, Changing response routing is out of scope of the outbound spec. thanks, -rohan On Apr 27, 2007, at 5:36 AM, sergiole@tml.hut.fi wrote: > > Hi, > > > Thank you for your answer. > > > We are composing an email with comments about why this issue (to > use the information in the Via header to handle Responses for > Requests originated by a UAC) may be not a good approach and bring > down several good outbound features. > > But before to send our comments, it is important for us to ask the > authors if they are considering to re-use the flow in a non- > outbound-required UAC-->UAS Request case. Details are explained below. > > > Keep in mind that in the comments below we focus our thoughts > mainly to connection oriented protocols (TCP). > > > Let me introduce an example; in the following scenario the UAC > previously established a flow with the EdgeProxy > > ----flow---- > UAC--------------EdgeProxy----UAS > > > Suppose now that the UAC wants to send a Request to the UAS. > > We understand that the purpose of a flow is to reach UAC for a > Request in the 'opposite direction' (i.e. a request from a UAS to > UAC). While now we are sending a Request from UAC to UAS. > > The question is: > > What are the authors point of view about re-using the flow in a > non-outbound-required UAC-->UAS Request? > > In other words, is an outbound UAC expected to reuse the outbound- > flow, or not? ('or not' means : to create another 'traditional' SIP > connection). > > > The advantages to re-use a flow in UAC-UAS direction can introduce > some additional features that can make of outbound a powerful > mechanism not only to just keep NAT/FW bindings alive to reach a > UAC but also to : a) increase security (proxying requests and > responses at the Edge Proxy could be always done using a > flowtoken), b) be an alternative to RFC 3581. > > We will add more details about the comments above and the > advantages that outbound can introduce by re-using a flow in any > direction to/from a UAC. But first we need to know what is the > authors position about using a flow in the (non-outbound-requiring) > UAC-UAS direction. > > > Regards > > Sergio > > > Quoting Kevin Johns : > >> Sergio, >> >> Thank you for clarifying your question. >> >> Let me try and provide some more detail, responses are always sent >> from >> the UAS to a UAC and are always routed based on the via header >> never the >> flow token. The flow token is only used for routing of initial >> requests >> from the edge proxy (UAC) to the client (UAS). >> >> Section 4.3 defines the UAC procedures (it is titled sending >> requests) >> and strongly recommends that the UA include the rport in the via >> header. >> When the Edge Proxy gets the INVITE, it will populate the rport >> parameter in the UAC inserted via head with the source port in the >> UDP >> header of the received packet. It will also insert the receive >> parameter >> into the same via header entry which contains the source IP >> address in >> the IP header of the received packet. The Edge Proxy then adds its >> own >> via header entry and forwards this INVITE along. >> >> When the edge proxy gets back the response, it will look at the >> top most >> Via header which contains the rport and receive parameter. The Edge >> Proxy will then forward the response to the UAC using these >> parameters >> which are routable since they represent the WAN interface of the NAT. >> The flow token never comes into play in this case. >> >> This is all defined in RFC 3581 (An Extension to the Session >> Initiation >> Protocol (SIP) for Symmetric Response Routing) >> >> I hope this helps clarify the situation. >> Kevin >> >> -----Original Message----- >> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi] >> Sent: Friday, April 20, 2007 8:59 AM >> To: Kevin Johns >> Cc: sip@ietf.org; Cullen Jennings; Rohan Mahy >> Subject: RE: [Sip] outbound08 - Handling Responses in Edge proxy / >> Viavs.Flowtoken >> >> >> Hi, >> >> >> Thank you for your answer. >> >> Perhaps I should emphasize that I am always talking about Edge >> Proxy >> behavior handling incoming Responses to be forwarded to a UAC over an >> existing flow. >> >> It seems that your answer is related to handling Responses in >> the UAC, >> not in the Edge Proxy. Nevertheless I add my comments below: >> >> >>> Outbound expects that rport is used in the via header for routing of >>> responses (for UDP that is) see the note in section 4.3. >> >> I understand that section 4.3 is for UA behavior. >> >>> Responses are >>> routed as defined in 3261 for TCP. >> >> Yes, but in the case of forwarding Responses to a flow in an Edge >> Proxy, I understand that the proxy uses the flowtoken information, >> thus >> discarding any consideration of the Via-header parameters >> (different to >> 3261 approach). >> >> So.. shouldn't outbound-08 draft explain the case of Responses >> handled >> by the Edge Proxy? By common sense I guess that the Response >> should use >> the destination stated in the flowtoken, but, as >> outbound-08 did not formally specify this case, why I could not avoid >> considering the destination in the Via-header (although it wont work >> with NAT)? >> >> Regards, >> >> Sergio >> >> >> >> Quoting Kevin Johns : >> >>> Sergio, >>> >>> Outbound expects that rport is used in the via header for routing of >>> responses (for UDP that is) see the note in section 4.3. >>> Responses are >> >>> routed as defined in 3261 for TCP. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: sergiole@tml.hut.fi [mailto:sergiole@tml.hut.fi] >>> Sent: Thursday, April 19, 2007 8:52 AM >>> To: sip@ietf.org >>> Cc: Cullen Jennings; Rohan Mahy >>> Subject: [Sip] outbound08 - Handling Responses in Edge proxy / Via >>> vs.Flowtoken >>> >>> >>> >>> Hi, >>> >>> >>> I have a question related to handling Responses that are going >>> to be >> >>> sent over a flow in an Edge proxy. >>> >>> In "5.3. Forwarding Requests (outbound08)" I read that a >>> Request is >> >>> forwarded to a flow using the information retrieved from the flow >>> token (and that it is found in the Route-header). >>> >>> Now I am considering how is the case for Responses. >>> >>> Should we consider the same behavior? i.e. forward a Response >>> over a >> >>> flow using the flowtoken found in the Path-header? >>> >>> In 'non-outbound SIP', as far as I understand, Route Header forces >>> the routing in Requests, and Via-header forces routing in Responses. >>> >>> So... should we avoid any consideration to the information >>> stored in >> >>> the topmost Via-header when proxying a Response? (And instead use >>> the >>> information in the flowtoken ?) >>> >>> I think that the answers is yes, since the Via could contain a >>> private address in the case of a NAT in the middle. Then, >>> shouldn't be >> >>> mentioned the response case in the draft? >>> >>> >>> Regards, >>> >>> >>> Sergio >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> sip-implementors@cs.columbia.edu for questions on current sip Use >>> sipping@ietf.org for new developments on the application of sip >>> >> >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 13:45:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1QiO-0005hG-H3; Thu, 21 Jun 2007 13:45:04 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1QiM-0005eN-R7 for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 13:45:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1QiM-0005eA-H4 for sip@ietf.org; Thu, 21 Jun 2007 13:45:02 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1QiK-0008Kw-3x for sip@ietf.org; Thu, 21 Jun 2007 13:45:02 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l5LHipp20627; Thu, 21 Jun 2007 10:44:51 -0700 In-Reply-To: <00ad01c789a8$5de68d10$0601a8c0@BEMBUSTER> References: <00ad01c789a8$5de68d10$0601a8c0@BEMBUSTER> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A5FD31D-6701-4140-9347-E5160FF23168@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Thu, 21 Jun 2007 10:44:50 -0700 To: Jeroen van Bemmel X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: sip@ietf.org, Rohan Mahy , Cullen Jennings Subject: [Sip] Re: outbound-08 : using different Contact URIs for different flows? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Jeroen, I don't think there is any problem here. If the UAC wants to put different Contact URIs with different reg-ids for the same instance- id, that is the business of the UAC. For a specific instance the authoritative proxy will pick one of the reg-ids and forward there. If the proxy gets a 430 response it will try the next one. The proxy will need to set the Request URI to the Contact URI of the desired reg-id for each attempt. thanks, -rohan On Apr 28, 2007, at 8:17 AM, Jeroen van Bemmel wrote: > All, > > While trying to implement GRUU and outbound in combination, I > stumbled upon a minor issue: what if the UAC uses different Contact > URIs when registering multiple flows. The examples in outbound > don't do this, but there is no explicit statement that this is not > allowed, and the example in 3.2 (line1@192.168.0.2>;reg-id=1) could > be seen as suggesting that the registration with reg-id=2 would use > "line2" > > See my previous mail: for GRUU this could mean that the authorative > proxy cannot select the right URI to rewrite with, there can be an > inconsistency between the temporary GRUU the UAC selected > (associated with a specific contact) and the request URI received. > > One solution may be to adapt the algorithm used to generate > temporary GRUUs. A second option, which is perhaps simpler, is to > simply state in outbound that the UAC MUST use identical Contact > URIs when registering multiple flows (in section 4.2), and that the > authoritative proxy MAY select any one of the registered Contact > URIs to rewrite with (e.g. needed to cover transitional cases where > the UAC obtains a new IP address and starts re-registering) > > Regards, > Jeroen > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 13:56:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qt8-0007j9-LI; Thu, 21 Jun 2007 13:56:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Qt7-0007j4-9r for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 13:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Qt7-0007iv-0H for sip@ietf.org; Thu, 21 Jun 2007 13:56:09 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Qt5-0001XR-MQ for sip@ietf.org; Thu, 21 Jun 2007 13:56:08 -0400 Received: by an-out-0708.google.com with SMTP id c17so139622anc for ; Thu, 21 Jun 2007 10:56:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X9gESVjXskzhXiNKik3rmkZTu4jkqCFvi+4i/BkMGt319bGESE+CkQoViRe7q35dqhJvRCkZwzl/W1/Bn7avqYw71BzfrxKfCpCDrrbfvYW0ttKSqB7pfn626d41RbQiRNu5f71I7aHagYkRgbFkCKdrHS9AZ4xUdZuHMSoGPfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qmjphke4lWjqiOzG35oXGNi3NYtQ4sbFoS6fekqleNM3S4dyl0oSqzp8lHtt/hkZ7lxNmQWQPA3OX3lNIWhc5aM8zd6RlF98F4n4LoSGktGFnQf2lyUQAZS/UnqUBWtvubiRZR6AP+vKb+uKJCmOkT9y8lagXZvPhbwjYVtN4Dw= Received: by 10.100.11.7 with SMTP id 7mr1220509ank.1182448567234; Thu, 21 Jun 2007 10:56:07 -0700 (PDT) Received: by 10.100.153.16 with HTTP; Thu, 21 Jun 2007 10:56:07 -0700 (PDT) Message-ID: <953beacc0706211056j5b65c646t43088922152b59f2@mail.gmail.com> Date: Thu, 21 Jun 2007 10:56:07 -0700 From: "Rohan Mahy" To: "Erkki.Koivusalo@nokia.com" Subject: Re: [Sip] Keepalive mechanisms for TCP flows in outbound-08 In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: sip@ietf.org, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Erkki, At IETF68 we agreed to add an indicator "timed-keepalive" that the *server* expects keepalives to happen according to the timers recommended in the draft. If the server asks for this, then the client needs to send pings (STUN over UDP or double CRLF over TCP or TLS). The *client* can tell if the server will send pongs (STUN binding responses over UDP, or single CRLF over TCP or TLS) if the server advertises "keep-stun" or "keep-crlf". This allows a battery operated client to use TCP keepalives or send pings less often if the server allows, and it allows the client in general to know if they should expect to receive pongs. thanks, -rohan On 3/8/07, Erkki.Koivusalo@nokia.com wrote: > Hi, > > >> Question 1: > >> > >> Is the single CRLF "pong" necessary or could the UA detect the > >> flow failure just by receiving a socket or ICMP error when the > >> connection is broken and not able to pass the double-CRLF "ping" > >> to the proxy ? > > > >Sure, if you don't mind not getting calls for 10 minutes. And if some > >moron hasn't blocked ICMP on your network (which unfortunately > >corpsec guidelines frequently recommend). > > To overcome this problem, doesn't Outbound strongly promote the > UA registering over multiple flows ? > > This requires the UA to detect when a flow fails. Since > such detection takes time and leaves a window of opportunity for > missed incoming requests, this mechanism allows the UA to use > multiple flows to the proxy or registrar. > > Are you suggesting that this mechanism in the Outbound only > has limited or even no value ? > > >It can take TCP a LONG time to know a flow has failed. This is a > >large part of why I liked the STUN model. > > How does the addition of CRLF keepalive without CRLF "pong" > make the situation worse compared using TCP keepalive, which > has been considered acceptable for Outbound over several > successive draft revisions and is still there without any > "pong" other than TCP ACK ? > > And as you say, it can take TCP a LONG time to know a flow has failed, > but not necessarily. The device which rebooted might indicate the > broken connection by sending TCP RST, which immediately tells the > sender about the flow failure. > > Even the STUN over TCP model will not guarantee an immediate > detection of a failed flow as Outbound suggests that the time > between successive keepalives over TCP should be between 95 and > 120 seconds on top of which the STUN transaction adds 8 seconds > to wait for the response. So even with STUN or CRLF "ping-pong" > you could not getting calls for two minutes if the UA is relying > on one single flow only or using two flows towards two different > proxies over a single NAT which reboots. > > > I am still questioning whether the requirement to add CRLF "pong" > and 'keep-crlf' URI tags are really worth the extra complexity. > Personally I am not at all convinced about it. > > Regards, > > Erkki > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 19:49:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WOX-000497-Jq; Thu, 21 Jun 2007 19:48:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1WOW-000492-1I for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 19:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WOV-00048u-Ng for sip@ietf.org; Thu, 21 Jun 2007 19:48:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WOU-0002Gj-CV for sip@ietf.org; Thu, 21 Jun 2007 19:48:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 19:48:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAEqrekZAZnme/2dsb2JhbACIVaQu X-IronPort-AV: i="4.16,449,1175486400"; d="scan'208"; a="63405160:sNHT30666252" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5LNmr9F017161; Thu, 21 Jun 2007 19:48:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LNmrLf003077; Thu, 21 Jun 2007 23:48:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 19:48:52 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 19:48:52 -0400 Message-ID: <467B0E61.3090101@cisco.com> Date: Thu, 21 Jun 2007 19:48:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Arunachalam Venkatraman (arunvenk)" Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFYtransaction has completed? References: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Jun 2007 23:48:52.0601 (UTC) FILETIME=[B8EFFE90:01C7B45E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2156; t=1182469733; x=1183333733; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Could=20a=20UA=20issue=20a=20new=20NOTIFY=20b efore=20the=20previous=09NOTIFYtransaction=0A=20has=20completed? |Sender:=20 |To:=20=22Arunachalam=20Venkatraman=20(arunvenk)=22=20; bh=erCY9F8q0+NxuwU09ZjXKIgXwPf0nj7VT1++SHItEp8=; b=jl/XIW9OX1mB0xtnXJTMS6+XaFAsUpRNUS4MqreWInf9eH+aVnjBvPMcytwNmp5pLWCO7rCC rOEIpfSXkPtNT5jrx/izGALbcrOjv8pIMD/llmZ3eml14yzqJGuUTbgB; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: sip@ietf.org, yan X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Arunachalam Venkatraman (arunvenk) wrote: > However, if you are using UDP and if the data in the second NOTIFY is > additive to and not replacing the prior NOTIFY, you may run into the > issue of out-of-sequence delivery. This can be a problem even when using TCP if there are proxies in the path. There is no requirement for proxies to deliver messages in the order they receive them. Paul > ------------------------------------------------------------------------ > > *From:* Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* Wednesday, June 20, 2007 12:18 PM > *To:* yan > *Cc:* sip@ietf.org > *Subject:* Re: [Sip] Could a UA issue a new NOTIFY before the previous > NOTIFYtransaction has completed? > > > > Generally speaking, yes. > > > > An individual event package may restrict that behavior though. > > > > RjS > > > > On Jun 15, 2007, at 12:16 PM, yan wrote: > > > > hi: > > Could anyone answer me the question: > > Can a UA issue a new NOTIFY before the previous NOTIFY transaction has > completed? > > thx > > > > yan > > > > ------------------------------------------------------------------------ > > 150 Íò ÈË Í¬ ʱ ÔÚ Íæ µÄ Íø ÓΣ¬Äã ²» ÊÔ ÊÔ Â𠣿 > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu > for questions on current sip > > Use sipping@ietf.org for new developments on > the application of sip > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 21:05:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XaQ-0007IQ-B7; Thu, 21 Jun 2007 21:05:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1XaO-0007DW-HQ for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 21:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XaO-0007DO-7o for sip@ietf.org; Thu, 21 Jun 2007 21:05:16 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XaN-0003lU-I2 for sip@ietf.org; Thu, 21 Jun 2007 21:05:16 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK0004PXIZIG8@szxga04-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:04:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK000EIHIZH3Q@szxga04-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:04:30 +0800 (CST) Received: from q28189a ([10.85.28.227]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK00037WIZGVQ@szxml04-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:04:29 +0800 (CST) Date: Fri, 22 Jun 2007 09:04:31 +0800 From: Bruce Qi Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previousNOTIFYtransaction has completed? To: SIP , Paul Kyzivat Message-id: <003701c7b469$4aa26170$e31c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal References: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com> <467B0E61.3090101@cisco.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Peili Xu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0037851642==" Errors-To: sip-bounces@ietf.org --===============0037851642== Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgUGF1bDoNCiAgICAgICBJcyBUaGlzIGlzc3VlIGJlbG9uZyB0byB0aGUgaW50ZXJuYWwgaW1w bGVtZW50YXRpb24gb2YgU0lQIHByb2R1Y3Rpb24/IEJlYWN1c2UgSSB0aGluayB0aGVyZSBhcmUg bWFueSBzaW1pbGFyIGlzc3VlcyBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgU0lQIHByb2R1Y3Rpb24u DQoNClRoYW5rcyBhbmQgUmVnYXJkcw0KQnVyY2UgUWkNCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIA0KRnJvbTogIlBhdWwgS3l6aXZhdCIgPHBreXppdmF0QGNpc2NvLmNvbT4NClRv OiAiQXJ1bmFjaGFsYW0gVmVua2F0cmFtYW4gKGFydW52ZW5rKSIgPGFydW52ZW5rQGNpc2NvLmNv bT4NCkNjOiA8c2lwQGlldGYub3JnPjsgInlhbiIgPGNvbWV0X3lhbkAxNjMuY29tPg0KU2VudDog RnJpZGF5LCBKdW5lIDIyLCAyMDA3IDc6NDggQU0NClN1YmplY3Q6IFJlOiBbU2lwXSBDb3VsZCBh IFVBIGlzc3VlIGEgbmV3IE5PVElGWSBiZWZvcmUgdGhlIHByZXZpb3VzIE5PVElGWSB0cmFuc2Fj dGlvbiBoYXMgY29tcGxldGVkPw0KDQoNCj4gDQo+IA0KPiBBcnVuYWNoYWxhbSBWZW5rYXRyYW1h biAoYXJ1bnZlbmspIHdyb3RlOg0KPj4gSG93ZXZlciwgaWYgeW91IGFyZSB1c2luZyBVRFAgYW5k IGlmIHRoZSBkYXRhIGluIHRoZSBzZWNvbmQgTk9USUZZIGlzIA0KPj4gYWRkaXRpdmUgdG8gYW5k IG5vdCByZXBsYWNpbmcgdGhlIHByaW9yIE5PVElGWSwgeW91IG1heSBydW4gaW50byB0aGUgDQo+ PiBpc3N1ZSBvZiBvdXQtb2Ytc2VxdWVuY2UgZGVsaXZlcnkuDQo+IA0KPiBUaGlzIGNhbiBiZSBh IHByb2JsZW0gZXZlbiB3aGVuIHVzaW5nIFRDUCBpZiB0aGVyZSBhcmUgcHJveGllcyBpbiB0aGUN Cj4gcGF0aC4gVGhlcmUgaXMgbm8gcmVxdWlyZW1lbnQgZm9yIHByb3hpZXMgdG8gZGVsaXZlciBt ZXNzYWdlcyBpbiB0aGUNCj4gb3JkZXIgdGhleSByZWNlaXZlIHRoZW0uDQo+IA0KPiBQYXVsDQo+ IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+ICpGcm9tOiogUm9iZXJ0IFNwYXJrcyBbbWFp bHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXQ0KPj4gKlNlbnQ6KiBXZWRuZXNkYXksIEp1bmUgMjAs IDIwMDcgMTI6MTggUE0NCj4+ICpUbzoqIHlhbg0KPj4gKkNjOiogc2lwQGlldGYub3JnDQo+PiAq U3ViamVjdDoqIFJlOiBbU2lwXSBDb3VsZCBhIFVBIGlzc3VlIGEgbmV3IE5PVElGWSBiZWZvcmUg dGhlIHByZXZpb3VzIA0KPj4gTk9USUZZdHJhbnNhY3Rpb24gaGFzIGNvbXBsZXRlZD8NCj4+IA0K Pj4gIA0KPj4gDQo+PiBHZW5lcmFsbHkgc3BlYWtpbmcsIHllcy4NCj4+IA0KPj4gIA0KPj4gDQo+ PiBBbiBpbmRpdmlkdWFsIGV2ZW50IHBhY2thZ2UgbWF5IHJlc3RyaWN0IHRoYXQgYmVoYXZpb3Ig dGhvdWdoLg0KPj4gDQo+PiAgDQo+PiANCj4+IFJqUw0KPj4gDQo+PiAgDQo+PiANCj4+IE9uIEp1 biAxNSwgMjAwNywgYXQgMTI6MTYgUE0sIHlhbiB3cm90ZToNCj4+IA0KPj4gDQo+PiANCj4+IGhp Og0KPj4gDQo+PiAgIENvdWxkIGFueW9uZSBhbnN3ZXIgbWUgdGhlIHF1ZXN0aW9uOg0KPj4gDQo+ PiBDYW4gYSBVQSBpc3N1ZSBhIG5ldyBOT1RJRlkgYmVmb3JlIHRoZSBwcmV2aW91cyBOT1RJRlkg dHJhbnNhY3Rpb24gaGFzIA0KPj4gY29tcGxldGVkPw0KPj4gDQo+PiAgdGh4DQo+PiANCj4+ICAN Cj4+IA0KPj4geWFuDQo+PiANCj4+ICANCj4+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+ IDE1MCDN8iDIyyDNrCDKsSDU2iDN5iC1xCDN+CDTzqOsxOMgsrsgytQgytQgwvAgo78gDQo+PiA8 aHR0cDovL2V2ZW50Lm1haWwuMTYzLmNvbS9jaGFuZWwveHlxLmh0bT9mcm9tPTE2M19OTzE+DQo+ PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiANCj4+IFNpcCBtYWlsaW5nIGxpc3QgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcA0KPj4gDQo+PiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0 aGUgY29yZSBTSVAgUHJvdG9jb2wNCj4+IA0KPj4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29s dW1iaWEuZWR1IA0KPj4gPG1haWx0bzpzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdT4g Zm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KPj4gDQo+PiBVc2Ugc2lwcGluZ0BpZXRmLm9y ZyA8bWFpbHRvOnNpcHBpbmdAaWV0Zi5vcmc+IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIA0KPj4g dGhlIGFwcGxpY2F0aW9uIG9mIHNpcA0KPj4gDQo+PiAgDQo+PiANCj4+IA0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiBTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaXANCj4+IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVsb3BtZW50IG9mIHRo ZSBjb3JlIFNJUCBQcm90b2NvbA0KPj4gVXNlIHNpcC1pbXBsZW1lbnRvcnNAY3MuY29sdW1iaWEu ZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXANCj4+IFVzZSBzaXBwaW5nQGlldGYub3Jn IGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXAg bWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAN Cj4gVGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3Rv Y29sDQo+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25z IG9uIGN1cnJlbnQgc2lwDQo+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1l bnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCj4= --===============0037851642== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0037851642==-- From sip-bounces@ietf.org Thu Jun 21 21:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XtQ-0006BH-2m; Thu, 21 Jun 2007 21:24:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1XtO-00069M-JB for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 21:24:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XtO-00069E-9Q for sip@ietf.org; Thu, 21 Jun 2007 21:24:54 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XtM-0004GM-Sp for sip@ietf.org; Thu, 21 Jun 2007 21:24:54 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jun 2007 03:24:53 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI7BekaQ/uCKh2dsb2JhbACPJQIJDiw X-IronPort-AV: i="4.16,449,1175464800"; d="scan'208"; a="146223535:sNHT29276874" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5M1OpId027108; Fri, 22 Jun 2007 03:24:51 +0200 Received: from dwingwxp (dhcp-128-107-163-120.cisco.com [128.107.163.120]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5M1OkTC024411; Fri, 22 Jun 2007 01:24:46 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" , "'Drage, Keith \(Keith\)'" Subject: RE: [Sip] Certificate authentication in SIP Date: Thu, 21 Jun 2007 18:24:45 -0700 Message-ID: <1d3501c7b46c$21a77a00$c2f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace0GrCyB03UtlYiQSyDUSVLRr5YjQAUKM+A In-Reply-To: <467A9C2F.6070209@alcatel-lucent.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3430; t=1182475491; x=1183339491; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=z71qw+EQBP2KVZn8oQPuGDTJX7rma+qQBT+OwI25Qc4=; b=LMScBlq8P2nunbsHT81aTV8XbRg1AaJ11VPjJdd34kIkwuINP9snAECAJpopfCb3sX6l0i9H wIJk6TIKtVzkJIhWYn2loUolrFVxMEoKsq/N7ItmL/B3ycgx7bdgBw3q; Authentication-Results: ams-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'SIP LIST' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org > I must confess that on an initial reading of the draft, I was > lost on the need for requirements that add certificate > authentication to SIP. Using TLS, a registrar and a UAC and > exchange certificates today and authenticate each other, > without resorting to a shared secret, right? With TLS, the UAC can authenticate its proxy, yes. But the establishment of a TLS session, even mutually-authenticated TLS (which is not mandated by RFC3261, by the way) doesn't inheriently provide authentication of the REGISTER message. I suppose it _could_, but we don't have that written down anywhere that I'm aware of. > I beleive the use case that the author is going for has to do with > using the hop-by-hop signaling path through a SIP proxy mesh to a > registrar, but being able to exchange certificates directly > between the UAC and the registrar. Yes, exactly. -d > As such, the title of the > draft ought to be reflective of this; something along the lines > of "Requirements for direct registrar authentication in the > Session Initiation Protocol (SIP) by a User Agent Client (UAC)". > > > - whether the problem space exists but is something slightly > > different, and if so what is that problem space? > > If the problem space is defined as coming up with requirements > for direct registrar authentication in SIP by a UAC over a > normal SIP proxy mesh, then that is a reasonable problem space, > IMHO. > > > - whether there is a more general problem that the security area > > should be addressing, rather than the SIP group addressing something > > specific? > > I beleive that this is fairly specific to SIP, but will defer > to the chairs and the rest of the WG. > > > - based on your answers to the first three questions, whether this > > draft is essentially in the right direction to be adopted as the WG > > draft assuming we create the charter item, or whether we > > need to seek some other input draft? > > This draft also talks about interpreting the contents of the > certificates (S3, requirement 8). As such, some of the work Scott > Lawrence and I have done in domain-certs provides more > guidelines on this particular aspect. We received good feedback > from the pkix WG in Prague when we presented domain-certs > there; we are in the process of revising the domain-certs draft > to include a discrete set of steps that can be programmed to > do certificate validation. We should be sending a revised > version of this draft out by tomorrow. > > > - and finally, whether (assuming we go ahead with this work) there > > is any work in any other IETF WG that we should take account of? > > domain-certs, as mentioned above. In addition, sip-sipsec could > provide a possible solution set; it appears to fit some of the > requirements. > > Thanks. > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 21 21:34:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Y2J-0005bK-7W; Thu, 21 Jun 2007 21:34:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1Y2H-0005a5-V5 for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 21:34:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Y2H-0005Zx-LS for sip@ietf.org; Thu, 21 Jun 2007 21:34:05 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Y2H-0000QJ-6Y for sip@ietf.org; Thu, 21 Jun 2007 21:34:05 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK000CAKKBHCQ@szxga02-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:33:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK000FVWKBGDO@szxga02-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:33:17 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK0003LYKBBVQ@szxml04-in.huawei.com> for sip@ietf.org; Fri, 22 Jun 2007 09:33:16 +0800 (CST) Date: Fri, 22 Jun 2007 09:33:11 +0800 From: Qian Sun Subject: RE: [Sip] Comments on draft-camarillo-sip-body-handling-01 In-reply-to: <467A7478.7030405@cisco.com> To: 'Paul Kyzivat' Message-id: <001201c7b46d$4bdd55a0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Thread-index: Ace0AwJPUjFus6sQSWumqiFq0x6KcgAaBucQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'IETF SIP List' , Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, Thanks, Paul. So if a UA wants a SIP request triggered by the REFER to include a specified body, we can not use the hname "body". Can we define a new disposition type to explicitly indicate the triggered SIP request by REFER should carry the corresponding content body? For example: REFER sip:uac1@example.com SIP/2.0 Refer-To: Content-Type: text/plain Content-Disposition: referred-body Hello World! Then the MESSAGE triggered by the REFER will include the content which disposition type is "referred-body", i.e., "Hello World!" Cheers, Qian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, June 21, 2007 8:52 PM To: Qian Sun Cc: Gonzalo.Camarillo@ericsson.com; 'IETF SIP List' Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 Qian Sun wrote: > Hello, > > In section 4.3, there is the following text: > "(e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response." > > Can I include a Content-ID URL like this? > Refer-To: > And the Content-ID URL point to a body part, whose disposition type is not ' recipient-list', might be 'session'. The construction seems to be nonsense. When the REFER containing this is acted upon it would result in an INVITE with a body containing the CID URI. I assume you want the resulting INVITE to have the referenced body part as its body. That sounds possibly useful, but I don't see any way to disambiguate the cases. The use of "body" as a SIP URI parameter is interesting for completeness with header parameters, but I have never seen a use of it. The use of header parameters in general is pretty limited. > Maybe this draft could write something about the special hname "body", since the purpose of the draft is to clarify how message bodies are handled in SIP. It seems off-topic to what the draft is otherwise tackling. Paul > Cheers, > Qian > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 22 08:49:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iZe-0000rN-Ku; Fri, 22 Jun 2007 08:49:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1iZc-0000rA-Uj for sip-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 08:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iZc-0000r2-LC for sip@ietf.org; Fri, 22 Jun 2007 08:49:12 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iZc-0003yK-8P for sip@ietf.org; Fri, 22 Jun 2007 08:49:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2007 08:49:12 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwPAFZie0ZAZnme/2dsb2JhbACIV6IO X-IronPort-AV: i="4.16,451,1175486400"; d="scan'208"; a="124311301:sNHT87837850" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5MCnB7q029991; Fri, 22 Jun 2007 08:49:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MCn7Lj004433; Fri, 22 Jun 2007 12:49:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:49:07 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 08:49:07 -0400 Message-ID: <467BC543.6050009@cisco.com> Date: Fri, 22 Jun 2007 08:49:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Bruce Qi Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previousNOTIFYtransaction has completed? References: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com> <467B0E61.3090101@cisco.com> <003701c7b469$4aa26170$e31c550a@china.huawei.com> In-Reply-To: <003701c7b469$4aa26170$e31c550a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jun 2007 12:49:07.0336 (UTC) FILETIME=[B8B1A880:01C7B4CB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3454; t=1182516551; x=1183380551; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Could=20a=20UA=20issue=20a=20new=20NOTIFY=20b efore=20the=20previousNOTIFYtransaction=0A=20has=20completed? |Sender:=20 |To:=20Bruce=20Qi=20; bh=qWrCb691kH53nehcZEOZpxYCUV6s0lAYNRWTiPPbbb0=; b=boQRMLQdmu5HpQo56cTGkiKQBjGPs8GSlo1TcsJud+cyqNYr3fDpT1eKe7l36Lj50eiGdYwg yrvj3lqoBtz7fDW/8QclP1phfejjFRPGEef/0DxdNFSKUoGcr63RkFPq; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: SIP , Peili Xu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Bruce Qi wrote: > Hi Paul: > Is This issue belong to the internal implementation of SIP production? Beacuse I think there are many similar issues in the development of SIP production. Sorry - I don't understand your question. But in general there are potential issues of this sort in sending one request on a dialog before a prior request has completed. It is best to be avoided, though in certain cases it may be ok. Paul > Thanks and Regards > Burce Qi > > > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Arunachalam Venkatraman (arunvenk)" > Cc: ; "yan" > Sent: Friday, June 22, 2007 7:48 AM > Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFY transaction has completed? > > >> >> Arunachalam Venkatraman (arunvenk) wrote: >>> However, if you are using UDP and if the data in the second NOTIFY is >>> additive to and not replacing the prior NOTIFY, you may run into the >>> issue of out-of-sequence delivery. >> This can be a problem even when using TCP if there are proxies in the >> path. There is no requirement for proxies to deliver messages in the >> order they receive them. >> >> Paul >> >>> ------------------------------------------------------------------------ >>> >>> *From:* Robert Sparks [mailto:rjsparks@nostrum.com] >>> *Sent:* Wednesday, June 20, 2007 12:18 PM >>> *To:* yan >>> *Cc:* sip@ietf.org >>> *Subject:* Re: [Sip] Could a UA issue a new NOTIFY before the previous >>> NOTIFYtransaction has completed? >>> >>> >>> >>> Generally speaking, yes. >>> >>> >>> >>> An individual event package may restrict that behavior though. >>> >>> >>> >>> RjS >>> >>> >>> >>> On Jun 15, 2007, at 12:16 PM, yan wrote: >>> >>> >>> >>> hi: >>> >>> Could anyone answer me the question: >>> >>> Can a UA issue a new NOTIFY before the previous NOTIFY transaction has >>> completed? >>> >>> thx >>> >>> >>> >>> yan >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> 150 Íò ÈË Í¬ ʱ ÔÚ Íæ µÄ Íø ÓΣ¬Äã ²» ÊÔ ÊÔ Â𠣿 >>> >>> >>> _______________________________________________ >>> >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> >>> This list is for NEW development of the core SIP Protocol >>> >>> Use sip-implementors@cs.columbia.edu >>> for questions on current sip >>> >>> Use sipping@ietf.org for new developments on >>> the application of sip >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 22 09:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j0u-0006qA-2w; Fri, 22 Jun 2007 09:17:24 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1j0s-0006hl-HJ for sip-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 09:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1j0s-0006gP-6a for sip@ietf.org; Fri, 22 Jun 2007 09:17:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1j0r-0004zz-4l for sip@ietf.org; Fri, 22 Jun 2007 09:17:22 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2007 06:17:20 -0700 X-IronPort-AV: i="4.16,451,1175497200"; d="scan'208"; a="170216356:sNHT60958854" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5MDHK8w025414; Fri, 22 Jun 2007 06:17:20 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l5MDGtlE029482; Fri, 22 Jun 2007 13:17:20 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:17:19 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 09:17:18 -0400 Message-ID: <467BCBDD.7050103@cisco.com> Date: Fri, 22 Jun 2007 09:17:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Qian Sun Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 References: <001201c7b46d$4bdd55a0$7c6c460a@china.huawei.com> In-Reply-To: <001201c7b46d$4bdd55a0$7c6c460a@china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 13:17:18.0995 (UTC) FILETIME=[A9005630:01C7B4CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3769; t=1182518240; x=1183382240; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Comments=20on=20draft-camarillo-sip-body-hand ling-01 |Sender:=20; bh=gmJR50A4F9J4gikHykp5OxyEv5Ma3++pV30ADWxaNOk=; b=QH0lmc9+vggcI+wQWF5D/dgt/dqdtD6zfmhjc9ruQCYoOd99pWnV/JYmEEkwuhLRrwEacvol FoTgmujvnxCyHDrNsrJL1pDZEIrBw6ip3ezhaInBAtqlq6TacIrMkeHY; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: 'IETF SIP List' , Gonzalo.Camarillo@ericsson.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Qian Sun wrote: > Hello, > Thanks, Paul. So if a UA wants a SIP request triggered by > the REFER to include a specified body, we can not use the > hname "body". You can use "body" - but then the *value* of the body to be included is taken from the value of the "body" parameter. I just searched through my collection of sip drafts and RFCs (several years worth) for uses of this, and I only found three: draft-mahy-sip-peer-3pcc-00 (2002 - expired) draft-johnston-sipping-cc-uui-01 (2007 - active) draft-ietf-sipping-transc-conf-03 (2006 - in RFC Ed Queue) Of these, draft-ietf-sipping-transc-conf-03 doesn't show an actual encoded body - it just proposes use without showing it. But at least it appears a plausible use. The usage shown in the other two is, IMO, questionable. I think it remains to be seen if this construct will actually be supported. The use of header parameters of this sort, by the receiving UA is discretionary. It must be, because there are security risks to doing whatever someone asks you to do. So I don't think you can in general be confident that your request will be honored if you use this mechanism. > Can we define a new disposition type to explicitly > indicate the triggered SIP request by REFER should carry the > corresponding content body? > > For example: > REFER sip:uac1@example.com SIP/2.0 > Refer-To: > Content-Type: text/plain > Content-Disposition: referred-body > Hello World! I suppose you could propose such a change. I don't know if it would be accepted. > Then the MESSAGE triggered by the REFER will include the > content which disposition type is "referred-body", i.e., > "Hello World!" What are you trying to achieve by all of this? Paul > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, June 21, 2007 8:52 PM > To: Qian Sun > Cc: Gonzalo.Camarillo@ericsson.com; 'IETF SIP List' > Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 > > Qian Sun wrote: >> Hello, >> >> In section 4.3, there is the following text: >> "(e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response." >> >> Can I include a Content-ID URL like this? >> Refer-To: >> And the Content-ID URL point to a body part, whose disposition type is not ' recipient-list', might be 'session'. > > The construction seems to be nonsense. When the REFER containing this is > acted upon it would result in an INVITE with a body containing the CID URI. > > I assume you want the resulting INVITE to have the referenced body part > as its body. That sounds possibly useful, but I don't see any way to > disambiguate the cases. > > The use of "body" as a SIP URI parameter is interesting for completeness > with header parameters, but I have never seen a use of it. The use of > header parameters in general is pretty limited. > >> Maybe this draft could write something about the special hname "body", since the purpose of the draft is to clarify how message bodies are handled in SIP. > > It seems off-topic to what the draft is otherwise tackling. > > Paul > >> Cheers, >> Qian >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 22 14:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nyP-0004tj-W5; Fri, 22 Jun 2007 14:35:09 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1nyO-0004tW-Lq for sip-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 14:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nyO-0004tD-C3 for sip@ietf.org; Fri, 22 Jun 2007 14:35:08 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1nx4-0000kG-QT for sip@ietf.org; Fri, 22 Jun 2007 14:33:48 -0400 X-VirusChecked: Checked X-Env-Sender: Uri.Baniel@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1182537221!16806604!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 6099 invoked from network); 22 Jun 2007 18:33:41 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-7.tower-119.messagelabs.com with SMTP; 22 Jun 2007 18:33:41 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l5MIXaZ4011095 for ; Fri, 22 Jun 2007 11:33:40 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l5MIXZMJ004341 for ; Fri, 22 Jun 2007 13:33:36 -0500 (CDT) Received: from de01exm71.ds.mot.com (de01exm71.am.mot.com [10.176.8.27]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l5MIXYFq004318 for ; Fri, 22 Jun 2007 13:33:34 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Jun 2007 14:33:32 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authentication of the called party... thread-index: Ace0+9ZGEZZqvgnMS4K2DfbcK3B2bg== From: "Baniel Uri-CUB001" To: , , X-Vontu: Pass X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Subject: [Sip] Authentication of the called party... X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799722855==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0799722855== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B4FB.D6C06B1D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B4FB.D6C06B1D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi. I have bumped into Question #19 from http://www.sipknowledge.com/SIP_Dev_Expert_Exam_Linked_from_most_wanted_ 42.htm. They ask there about possible cases when SIP client may get authenticated by a server.=20 =20 This makes me wonder: There does not seem to be a current way to authenticate a called party by a proxy right? (as the proxy-authenticate header may be used only in 4xx responses but not in INVITE), so we need to trust the registrar that it fulfilled its authentication job. But what if we like to keep registration interval very large (e.g. for sake of saving battery's life, keeping network quiet)? How can one make sure the security of the phone was not compromised at the meantime? =20 -uri ------_=_NextPart_001_01C7B4FB.D6C06B1D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi. I = have bumped=20 into Question #19 from http://www.sipknowledge.com/SIP_Dev_Expert_Exam_Linked_fro= m_most_wanted_42.htm.
They = ask there about=20 possible cases when SIP client may get authenticated by a server.=20
 
This = makes me=20 wonder: There does not seem to be a current way to authenticate a called = party=20 by a proxy right? (as the proxy-authenticate header may be used only in = 4xx=20 responses but not in INVITE), so we need to trust the registrar that it=20 fulfilled its authentication job. But what if we like to keep = registration=20 interval very large (e.g. for sake of saving battery's life, keeping = network=20 quiet)? How can one make sure the security of the phone was not = compromised at=20 the meantime?
 
-uri
------_=_NextPart_001_01C7B4FB.D6C06B1D-- --===============0799722855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0799722855==-- From sip-bounces@ietf.org Fri Jun 22 17:13:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qR2-000787-2F; Fri, 22 Jun 2007 17:12:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1qR0-00077x-OQ for sip-confirm+ok@megatron.ietf.org; Fri, 22 Jun 2007 17:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1qR0-00077p-Ep for sip@ietf.org; Fri, 22 Jun 2007 17:12:50 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1qQz-0005Y4-4S for sip@ietf.org; Fri, 22 Jun 2007 17:12:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5MLCivI000851; Fri, 22 Jun 2007 16:12:48 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5MLCha09080; Fri, 22 Jun 2007 16:12:43 -0500 (CDT) Message-ID: <467C3B4B.3050806@lucent.com> Date: Fri, 22 Jun 2007 16:12:43 -0500 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Jeffrey, Alan S A \(Alan\)" Subject: [Sip] Updated domain-certs draft (draft-gurbani-sip-domain-certs-05) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Folks: draft-gurbani-sip-domain-certs-05 has been submitted to the IETF archives. This version includes the guidance we got from the pkix WG in Prague. More specifically, this version focuses strictly on: - How to use and interpret the SIP identities in a X.509 certificate. - How to indicate that this particular certificate is for SIP usage. Based on feedback from -04, we have removed pinning references and connection reuse references. In addition, what goes in the subjectAltName and the detailed steps to interpret and validate it are provided from the viewpoint of user agents, proxies, and registrars. Until the -05 version appears in the archives, you can get it from: https://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-05.txt https://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-05.html Comments, questions and other feedback is much appreciated. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 24 07:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QNX-0005ZW-4d; Sun, 24 Jun 2007 07:35:39 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2QNV-0005ZP-J9 for sip-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 07:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QNV-0005ZG-94 for sip@ietf.org; Sun, 24 Jun 2007 07:35:37 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2QNT-0001M8-FC for sip@ietf.org; Sun, 24 Jun 2007 07:35:37 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B01618081 for ; Sun, 24 Jun 2007 17:05:36 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 573B218064 for ; Sun, 24 Jun 2007 17:05:36 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jun 2007 17:05:45 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] draft-gurbani-sip-sipsec-01 Date: Sun, 24 Jun 2007 17:05:34 +0530 Message-ID: <2C7074A1A040E54DA31B3E72C052FD5206F4D34C@BLR-EC-MBX04.wipro.com> In-Reply-To: <46783F90.4080405@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] draft-gurbani-sip-sipsec-01 Thread-Index: Aceysl4jdixcAp0NQpelptDJHlGp2gDn7Kfw References: <4671B5F3.1050606@alcatel-lucent.com><005601c7aed2$02a6f5d0$0601a8c0@BEMBUSTER><4672F349.8000203@cisco.com> <46769AD7.8010606@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF10E7A886@zrc2hxm0.corp.nortel.com><4676BE2B.2010109@alcatel-lucent.com> <4676BFAC.3010104@cisco.com><46772959.5010407@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E8E5@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF10EE3430@zrc2hxm0.corp.nortel.com><467805A1.5090406@alcatel-lucent.com><0D5F89FAC29E2C41B98A6A762007F5D019E9D0@GBNTHT12009MSX.gb002.siemens.net> <46783F90.4080405@alcatel-lucent.com> From: To: , , , X-OriginalArrivalTime: 24 Jun 2007 11:35:45.0140 (UTC) FILETIME=[CD9B5B40:01C7B653] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, john.elwell@siemens.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org One other forking scenario, that I am not sure will be handled by usage of 3xx: I have set up the forking so that if the call comes to ravi@work.com or ravi@home.com, call gets forked to both.=20 It would get handled in normal forking, but when the proxy returns 3xx, for the next CONNECT also it again keeps sending 3xx responses. How would this scenario be handled? Regards, Ravi. -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com] > Sent: Wednesday, June 20, 2007 2:12 AM > To: Elwell, John > Cc: IETF SIP List; Francois Audet; Paul Kyzivat; Dean Willis > Subject: Re: [Sip] draft-gurbani-sip-sipsec-01 >=20 > Elwell, John wrote: > > Vijay, > > > > This deals with straightforward forking scenarios. >=20 > OK; good. >=20 > > What about a proxy that is scripted to fork in parallel to two > > destinations, and then, if they both fail to answer, fork to a third > > destination? Or a proxy that is scripted to forward to one > > destination, and then, if it fails to answer after a certain time, > > fork to a second location without cancelling the request at the first > > destination? >=20 > Presumably, if the proxy understands the "Proxy-Require: sipsec" > option tag, it will follow the normative behavior of returning > the destinations in a 3xx instead of launching into the fork dance. > If it is a legacy proxy, it should reject the CONNECT request > on encountering a "Proxy-Require: sipsec" option tag. >=20 > Thanks. >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Jun 24 07:44:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QWN-00041L-PW; Sun, 24 Jun 2007 07:44:47 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2QWM-00041B-6D for sip-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 07:44:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2QWL-000413-St for sip@ietf.org; Sun, 24 Jun 2007 07:44:45 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2QWK-0003FV-2X for sip@ietf.org; Sun, 24 Jun 2007 07:44:45 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B39CF18081 for ; Sun, 24 Jun 2007 17:14:44 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 9B99E18064 for ; Sun, 24 Jun 2007 17:14:44 +0530 (IST) Received: from BLR-EC-MBX04.wipro.com ([10.201.50.165]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 24 Jun 2007 17:15:09 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 24 Jun 2007 17:14:42 +0530 Message-ID: <2C7074A1A040E54DA31B3E72C052FD5206F4D34E@BLR-EC-MBX04.wipro.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-gurbani-sip-sipsec-01 what goes on inside the TLS tunnel Thread-Index: Ace2VQ4YJ0X4mFAsRb+HsTfukrPNiA== From: To: X-OriginalArrivalTime: 24 Jun 2007 11:45:09.0932 (UTC) FILETIME=[1E3FC6C0:01C7B655] X-Spam-Score: 0.2 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Subject: [Sip] draft-gurbani-sip-sipsec-01 what goes on inside the TLS tunnel X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1349609957==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1349609957== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B655.1E29BB40" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B655.1E29BB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vijay, Dean, Francois, =20 would it be needed to specify what messaging can occur inside the established tunnel? I understand that the proxies do not need to know what goes on inside, but for the two end UAs to interwork, would that need to be clearly specified?=20 For example,=20 Can more than one Dialog go on inside the established tunnel?=20 Can messages of multiple Dialogs established across different tunnels be sent in other tunnels than in the one they were originally established in? (this affect the way in which SUB+NOT mechanism would work, OR the way lost TLS connections to be re-established in a new tunnel without dropping a Dialog.. etc) =20 Regards, Ravi. =20 -- =20 Ravishankar. G. Shiroor Wipro Technologies, Bangalore. =20 ravishankar.shiroor@wipro.com -- =20 ------_=_NextPart_001_01C7B655.1E29BB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vijay, Dean, = Francois,

 

would it be needed to specify what messaging can = occur inside the established tunnel? I understand that the proxies do not need = to know what goes on inside, but for the two end UAs to interwork, would = that need to be clearly specified?
For example,

Can more than one Dialog go on inside the established tunnel?

Can messages of multiple Dialogs established across different tunnels be sent in other tunnels than in the one they were = originally established in? (this affect the way in which SUB+NOT mechanism would = work, OR the way lost TLS connections to be re-established in a new tunnel = without dropping a Dialog.. etc)

 

Regards,

Ravi.

 

--

 

Ravishankar. G. Shiroor

Wipro Technologies, Bangalore.

 

ravishankar.shiroor@wipro.c= om

--

 

------_=_NextPart_001_01C7B655.1E29BB40-- --===============1349609957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1349609957==-- From sip-bounces@ietf.org Sun Jun 24 22:21:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2eC9-0002HS-Tc; Sun, 24 Jun 2007 22:20:49 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2eC8-0002HC-DT for sip-confirm+ok@megatron.ietf.org; Sun, 24 Jun 2007 22:20:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2eC8-0002H1-0V for sip@ietf.org; Sun, 24 Jun 2007 22:20:48 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2eC5-0001bT-3O for sip@ietf.org; Sun, 24 Jun 2007 22:20:47 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK600M4S6GZUA@szxga04-in.huawei.com> for sip@ietf.org; Mon, 25 Jun 2007 10:19:47 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK6006Q46GY42@szxga04-in.huawei.com> for sip@ietf.org; Mon, 25 Jun 2007 10:19:47 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK60016I6GURH@szxml03-in.huawei.com> for sip@ietf.org; Mon, 25 Jun 2007 10:19:45 +0800 (CST) Date: Mon, 25 Jun 2007 10:19:42 +0800 From: Qian Sun Subject: RE: [Sip] Comments on draft-camarillo-sip-body-handling-01 In-reply-to: <467BCBDD.7050103@cisco.com> To: 'Paul Kyzivat' Message-id: <000c01c7b6cf$4a5e7ba0$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: Ace0z6oy4XMPmUjwSN+U62+kwG6UPwB99rTg X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, Paul Your information is very useful. We are trying to achieve some application service features by using REFER method, the referred SIP request is needed to carry a specified message-body. But the hname "body" can only include very limited information, so we consider content-id mechanism. Now it seems a new disposition type may be better. To the security risk, I think this is an inherent question of REFER, RFC 3515 and REFERRED-BY have talked a lot about this. I greatly appreciate your help! Cheers, Qian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Friday, June 22, 2007 9:17 PM To: Qian Sun Cc: Gonzalo.Camarillo@ericsson.com; 'IETF SIP List' Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 Qian Sun wrote: > Hello, > Thanks, Paul. So if a UA wants a SIP request triggered by > the REFER to include a specified body, we can not use the > hname "body". You can use "body" - but then the *value* of the body to be included is taken from the value of the "body" parameter. I just searched through my collection of sip drafts and RFCs (several years worth) for uses of this, and I only found three: draft-mahy-sip-peer-3pcc-00 (2002 - expired) draft-johnston-sipping-cc-uui-01 (2007 - active) draft-ietf-sipping-transc-conf-03 (2006 - in RFC Ed Queue) Of these, draft-ietf-sipping-transc-conf-03 doesn't show an actual encoded body - it just proposes use without showing it. But at least it appears a plausible use. The usage shown in the other two is, IMO, questionable. I think it remains to be seen if this construct will actually be supported. The use of header parameters of this sort, by the receiving UA is discretionary. It must be, because there are security risks to doing whatever someone asks you to do. So I don't think you can in general be confident that your request will be honored if you use this mechanism. > Can we define a new disposition type to explicitly > indicate the triggered SIP request by REFER should carry the > corresponding content body? > > For example: > REFER sip:uac1@example.com SIP/2.0 > Refer-To: > Content-Type: text/plain > Content-Disposition: referred-body > Hello World! I suppose you could propose such a change. I don't know if it would be accepted. > Then the MESSAGE triggered by the REFER will include the > content which disposition type is "referred-body", i.e., > "Hello World!" What are you trying to achieve by all of this? Paul > Cheers, > Qian > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, June 21, 2007 8:52 PM > To: Qian Sun > Cc: Gonzalo.Camarillo@ericsson.com; 'IETF SIP List' > Subject: Re: [Sip] Comments on draft-camarillo-sip-body-handling-01 > > Qian Sun wrote: >> Hello, >> >> In section 4.3, there is the following text: >> "(e.g., a Refer-To header field with a Content-ID URL pointing to a body part whose disposition type is 'session'), the UAS SHOULD return a 415 (Unsupported Media Type) response." >> >> Can I include a Content-ID URL like this? >> Refer-To: >> And the Content-ID URL point to a body part, whose disposition type is not ' recipient-list', might be 'session'. > > The construction seems to be nonsense. When the REFER containing this is > acted upon it would result in an INVITE with a body containing the CID URI. > > I assume you want the resulting INVITE to have the referenced body part > as its body. That sounds possibly useful, but I don't see any way to > disambiguate the cases. > > The use of "body" as a SIP URI parameter is interesting for completeness > with header parameters, but I have never seen a use of it. The use of > header parameters in general is pretty limited. > >> Maybe this draft could write something about the special hname "body", since the purpose of the draft is to clarify how message bodies are handled in SIP. > > It seems off-topic to what the draft is otherwise tackling. > > Paul > >> Cheers, >> Qian >> >> >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 25 09:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oo2-0000tP-TP; Mon, 25 Jun 2007 09:40:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2oo1-0000tF-Ur for sip-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 09:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oo1-0000t7-EM for sip@ietf.org; Mon, 25 Jun 2007 09:40:37 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2onz-0006wL-8R for sip@ietf.org; Mon, 25 Jun 2007 09:40:37 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 01CCC2007F; Mon, 25 Jun 2007 09:40:35 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29797-01-7; Mon, 25 Jun 2007 09:40:33 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 30ACD2001D; Mon, 25 Jun 2007 09:40:28 -0400 (EDT) To: "IETF SIP" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 25 Jun 2007 09:40:26 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/25/2007 09:40:22 AM, Serialize complete at 06/25/2007 09:40:22 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 1.8 (+) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: drage@alcatel-lucent.com Subject: [Sip] (no subject) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1256309252==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1256309252== Content-Type: multipart/alternative; boundary="=_alternative 004B1D2285257305_=" This is a multipart message in MIME format. --=_alternative 004B1D2285257305_= Content-Type: text/plain; charset="US-ASCII" Sorry, I had missed this going by until someone pointed it out ... Basically, I would support this work in SIP WG, which does seem like the right place at least for requirements (can see where it goes next from there). > So can I hear opinions of the WG on: > > - whether this represents a problem space that the working group > should draft requirements on? SIP WG seems like as good a place as any, at least for requirements. > > - whether the problem space exists but is something slightly > different, and if so what is that problem space? Yes, the problem space exists. > > - whether there is a more general problem that the security area > should be addressing, rather than the SIP group addressing something > specific? Develop the *requirements* first, then ask this question. A worthy question for this list would be whether the requirements should expand to use cases beyond Registrar interactions (e.g to Invite, Subscribe/Notify, or to streaming uses, etc). Of course, the Security Area should be involved regardless, esp at solution time. > > - based on your answers to the first three questions, whether this > draft is essentially in the right direction to be adopted as the WG > draft assuming we create the charter item, or whether we need to seek > some other input draft? I believe it is close, modulo wondering about expansion beyond Register as above. (Could dicker over details...) > > - and finally, whether (assuming we go ahead with this work) there > is any work in any other IETF WG that we should take account of? Dunno. -- Peter Blatherwick -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Wednesday, June 13, 2007 9:58 AM To: IETF SIP List Subject: [Sip] Certificate authentication in SIP (As WG chair) http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 .txt Describes a set of requirements for: This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). This document is being presented with the intention of providing clear requirements to any potential solutions specifying certificate authentication within SIP networks. Supporting certificate authentication in SIP would provide strong authentication and increase the types of possible deployment scenarios. (Before we go any further, please forget all about the solutions document - that comes later and we are not dealing with it now) We need to decide whether there is support for a body of work in this area, and therefore whether we should charter some requirements work in the SIP WG. (Because this is security related we have agreed that SIP does the requirements drafting and not SIPPING) So can I hear opinions of the WG on: - whether this represents a problem space that the working group should draft requirements on? - whether the problem space exists but is something slightly different, and if so what is that problem space? - whether there is a more general problem that the security area should be addressing, rather than the SIP group addressing something specific? - based on your answers to the first three questions, whether this draft is essentially in the right direction to be adopted as the WG draft assuming we create the charter item, or whether we need to seek some other input draft? - and finally, whether (assuming we go ahead with this work) there is any work in any other IETF WG that we should take account of? Regards Keith Regards Keith _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip --=_alternative 004B1D2285257305_= Content-Type: text/html; charset="US-ASCII"
Sorry, I had missed this going by until someone pointed it out ...

Basically, I would support this work in SIP WG, which does seem like the right place at least for requirements (can see where it goes next from there).  

> So can I hear opinions of the WG on:
>
> -                 whether this represents a problem space that the working group
> should draft requirements on?
SIP WG seems like as good a place as any, at least for requirements.

>
> -                 whether the problem space exists but is something slightly
> different, and if so what is that problem space?
Yes, the problem space exists.

>
> -                 whether there is a more general problem that the security area
> should be addressing, rather than the SIP group addressing something
> specific?
Develop the *requirements* first, then ask this question.  A worthy question for this list would be whether the requirements should expand to use cases beyond Registrar interactions (e.g to Invite, Subscribe/Notify, or to streaming uses, etc).  Of course, the Security Area should be involved regardless, esp at solution time.  

>
> -                 based on your answers to the first three questions, whether this
> draft is essentially in the right direction to be adopted as the WG
> draft assuming we create the charter item, or whether we need to seek
> some other input draft?

I believe it is close, modulo wondering about expansion beyond Register as above.  (Could dicker over details...)

>
> -                 and finally, whether (assuming we go ahead with this work) there
> is any work in any other IETF WG that we should take account of?
Dunno.  

-- Peter Blatherwick


-----Original Message-----

From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]

Sent: Wednesday, June 13, 2007 9:58 AM

To: IETF SIP List

Subject: [Sip] Certificate authentication in SIP

(As WG chair)

http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03
.txt

Describes a set of requirements for:

  This document defines requirements for adding certificate
  authentication to the Session Initiation Protocol (SIP).  This
  document is being presented with the intention of providing clear
  requirements to any potential solutions specifying certificate
  authentication within SIP networks.  Supporting certificate
  authentication in SIP would provide strong authentication and
  increase the types of possible deployment scenarios.

(Before we go any further, please forget all about the solutions
document - that comes later and we are not dealing with it now)

We need to decide whether there is support for a body of work in this
area, and therefore whether we should charter some requirements work in
the SIP WG.

(Because this is security related we have agreed that SIP does the
requirements drafting and not SIPPING)

So can I hear opinions of the WG on:

-                 whether this represents a problem space that the working group
should draft requirements on?

-                 whether the problem space exists but is something slightly
different, and if so what is that problem space?

-                 whether there is a more general problem that the security area
should be addressing, rather than the SIP group addressing something
specific?

-                 based on your answers to the first three questions, whether this
draft is essentially in the right direction to be adopted as the WG
draft assuming we create the charter item, or whether we need to seek
some other input draft?

-                 and finally, whether (assuming we go ahead with this work) there
is any work in any other IETF WG that we should take account of?


Regards

Keith



Regards

Keith


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip

 --=_alternative 004B1D2285257305_=-- --===============1256309252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1256309252==-- From sip-bounces@ietf.org Mon Jun 25 10:20:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pQh-0003h2-S6; Mon, 25 Jun 2007 10:20:36 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2pQg-0003gn-7U for sip-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 10:20:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pQf-0003gf-SM; Mon, 25 Jun 2007 10:20:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2pQe-0003s6-Hb; Mon, 25 Jun 2007 10:20:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 55ED92AC79; Mon, 25 Jun 2007 14:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I2pQA-0005Qt-3T; Mon, 25 Jun 2007 10:20:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 25 Jun 2007 10:20:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sip@ietf.org Subject: [Sip] I-D Action:draft-ietf-sip-gruu-14.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@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 : Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-sip-gruu-14.txt Pages : 41 Date : 2007-06-25 Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called a Globally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-gruu-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-gruu-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-06-25101524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-gruu-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-gruu-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-06-25101524.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Mon Jun 25 14:15:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t6O-0005py-Gv; Mon, 25 Jun 2007 14:15:52 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2t6N-0005pt-PN for sip-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 14:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t6N-0005pl-Fl for sip@ietf.org; Mon, 25 Jun 2007 14:15:51 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2t6M-0002cX-Rh for sip@ietf.org; Mon, 25 Jun 2007 14:15:51 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5PIFos2011213 for ; Mon, 25 Jun 2007 13:15:50 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:15:50 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 20:15:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 20:15:39 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001339A99@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Publication request for draft-ietf-sip-gruu-14.txt Thread-Index: Ace3VNWE5kcaVnHsTqmowTNaRRS/uA== From: "DRAGE, Keith \(Keith\)" To: X-OriginalArrivalTime: 25 Jun 2007 18:15:46.0666 (UTC) FILETIME=[DA0B54A0:01C7B754] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Subject: [Sip] Publication request for draft-ietf-sip-gruu-14.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org (As WG chair) I have just requested publication of: http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt The next stage for submitting comments is therefore the IESG last call. The PROTO writeup submitted with the publication request is as follows. Please feel free to respond if you consider any of the information incorrect. Regards Keith ------------------------------------------------------------------------ --- PROTO writeup for http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu- 14.txt: "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU)=20 in the Session Initiation Protocol (SIP)" (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Keith Drage The document has been reviewed and is ready for forwarding to IESG for=20 publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document history: * draft-rosenberg-sipping-gruu-reqs-00 was submitted 29th July 2003 and=20 expired 27th January 2004. * draft-rosenberg-sipping-gruu-reqs-01 was submitted 20th October 2003=20 and expired 19th April 2004. * draft-rosenberg-sip-gruu-00 was submitted 20th October 2003 and=20 expired 19th April 2004. * draft-rosenberg-sip-gruu-01 was submitted 5th December 2003 and=20 expired 4th June 2004. * draft-ietf-sip-gruu-00 was submitted 6th January 2004 and expired 6th=20 July 2004. * draft-ietf-sip-gruu-01 was submitted 15th February 2004 and expired=20 15th August 2004. * draft-ietf-sip-gruu-02 was submitted 2nd July 2004 and expired 31st=20 December 2004. * draft-ietf-sip-gruu-03 was submitted 21st February 2005 and expired=20 22nd August 2005. * draft-ietf-sip-gruu-04 was submitted 14th July 2005 and expired 15th=20 January 2006. * draft-ietf-sip-gruu-05 was submitted 28th September 2005 and expired=20 1st April 2006. * draft-ietf-sip-gruu-06 was submitted 20th October 2005 and expired 23rd=20 April 2006. * draft-ietf-sip-gruu-07 was submitted 6th March 2006 and expired 7th=20 September 2006. * draft-ietf-sip-gruu-08 was submitted 14th June 2006 and expired 16th=20 December 2006. * draft-ietf-sip-gruu-09 was submitted 19th June 2006 and expired 21st=20 December 2006. * draft-ietf-sip-gruu-10 was submitted 31st July 2006 and expired 1st=20 February 2007. * draft-ietf-sip-gruu-11 was submitted 23rd October 2006 and expired 26th=20 April 2007. * draft-ietf-sip-gruu-12 was submitted 5th March 2007 and expires 6th=20 September 2007. * draft-ietf-sip-gruu-13 was submitted 9th April 2007 and expires 11th=20 October 2007. * draft-ietf-sip-gruu-14 was submitted 25th June 2007 and expires 27th=20 December 2007. WGLC was initiated in the SIP WG on draft-ietf-sip-gruu-00 on 13th January=20 2004 with comments requested by 28th January 2004. A second WGLC was=20 announced on draft-ietf-sip-gruu-03 on 5th July 2004 with comments requested=20 by 17th July 2004. A third WGLC was announced on draft-ietf-sip-gruu-06 on=20 26th October 2005 with comments requested by 6th November 2005. A fourth WGLC=20 was announced on draft-ietf-sip-gruu-10 on 5th August 2006 with comments requested by 21st August 2006. A fifth WGLC was announced on draft-ietf-sip- gruu-11 on 13th November 2006 with comments requested by 27th November 2006. Review was made and comments were received during the last call identified=20 above from: Andrew Allen, Jeroen van Bemmel, Vijay Gurbani, Paul Kyzivat,=20 Xavier Marjo, Eric Rescorla, Robert Sparks, Dale Worley, (with an indication=20 that all had performed a full review of the draft. During the course of the=20 work comments have also been made by at least the following: Jesus Javier=20 Arauz, Francois Audet, Darshan Bildikar, Spencer Dawkins, John Elwell,=20 Miguel Garcia, Michael Hammer, Juha Heinanen, Christer Holmberg, Cullen=20 Jennings, Erkki Koivusalo, Jiri Kuthan, Scott Lawrence, Rohan Mahy, Peter=20 Musgrave, Kasturi Narayanan, Aki Niemi, Klaus Nieminen, Sean Olsen, Michael=20 Proctor, Adam Roach, Brian Stucker, Dean Willis (in addition to the above).=20 See also the acknowledgements list in the document. See=20 http://www.softarmor.com/sipwg/reviews/gruu/index.html for documentation of=20 the final extensive review. There have been key issues in the discussion that have been resolved to the=20 satisfaction of the SIP working group, but which are worth mentioning here: * A grid parameter existed as part of the earlier drafts up to draft- ietf-sip-gruu-10. The GRID parameter was removed from GRUU in response=20 to comments received. Instead, loose routing is proposed to provide=20 the ability of 'end-instance switching'. The gr URI parameter=20 (formerly gruu URI parameter) now takes a value, replacing opaque as=20 the server-side 'switch'.=20 * Up to and including draft-ietf-sip-gruu-10, GRUU did not provide any=20 anonymity functions at all. Indeed, the recommendations for=20 construction of gruus were such that they would contain the users AOR.=20 The point was raised that there were many places, such as Europe,=20 where anonymous calls are the norm. This is because privacy laws=20 require that caller ID be given out as an opt-in feature, and the=20 default is privacy. Conclusion in -11 was that serial pseudonymity is=20 provided. A user is given lots of anonymous GRUU, allowing it to use a=20 different one for each call. Each remain valid the entire duration of=20 the registration. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? Whilst not specifically a security related document, the document has been=20 reviewed by Eric Rescorla (the security adviser to the SIP working group),=20 and there are no remaining unresolved issues. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. The document defines a new SIP protocol extension for a particular purpose=20 in a form that has been used for many other extensions. The document=20 shepherd has no concerns with the document. There is one patent disclosure against this document from Microsoft=20 Corporation. They have indicated they are prepared to license any rights on=20 the basis of "Reasonable and Non-Discriminatory License to All Implementers=20 with Possible Royalty/Fee". This has been brought to the attention of the=20 working group and no concerns were expressed. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been well discussed and extensively reviewed by a=20 significant number of members of the working group (see answer in 1(b)). (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated.=20 (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document has been reviewed against the guidelines in RFC 4485 and it is=20 believed that the document is conformant with those guidelines. While the document defines a new SIP option tag, these have been performed=20 as a SIP working group item, and therefore this draft is in conformance with=20 RFC 3427. The document passes ID-NITS (idnits 2.04.09) with the exception of the=20 following: ** There are 4 instances of too long lines in the document, the longest=20 one being 6 characters in excess of 72. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has split its references into normative and informative=20 references. All the normative references are appropriate normative=20 references. All the normative references are published except: * reference [13] to draft-ietf-sip-outbound which is still in the final=20 stages of development within the SIP working group. All the normative references are standards track documents except: * reference [4] to RFC 2119 which is a BCP. * reference [8] to RFC 3968 which is a BCP. * reference [9] to RFC 3969 which is a BCP. All the informative references are also published except: * reference [18] to draft-ietf-sipping-cc-transfer which is still in=20 progress in the SIPPING WG. * reference [27] to draft-ietf-sipping-gruu-reg-event for which=20 publication has been requested by the SIPPING WG. * reference [28] to draft-rosenberg-sip-ua-loose-route for which a charter milestone exists in the SIP WG, and for which this is a=20 candidate. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? Section 11.1 of the document registers two new header field parameters. This=20 registration is consistent with RFC 3968 which defines the registry and is=20 also consistent with the current format of the registry. Section 11.2 of the document registers a new SIP URI parameter. This=20 registration is consistent with RFC 3969 which defines the registry and is=20 also consistent with the current format of the registry. Section 11.3 of the document registers a new option-tag; the new option-tag=20 is defined elsewhere in the document. This registration is consistent with=20 RFC 3261 which defines the registry and is also consistent with the current=20 format of the registry. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The ABNF within the document passes the checks in Bill Fenner's ABNF parsing=20 web service. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Several applications of the Session Initiation Protocol (SIP) require a user=20 agent (UA) to construct and distribute a URI that can be used by anyone on=20 the Internet to route a call to that specific UA instance. A URI that=20 routes to a specific UA instance is called a Globally Routable UA URI (GRUU). =20 This document describes an extension to SIP for obtaining a GRUU from a=20 registrar and for communicating a GRUU to a peer within a dialog. Working Group Summary The document complements work already performed in RFC 4474 for=20 authenticated request identity, and forms an integral part of the chartered=20 work in this area. There is consensus in the working group to publish this=20 document. Document Quality The document has been well discussed by a significant number of members of=20 the working group.=20 Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. 'The IANA Expert(s) for the registries in=20 this document are . _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Jun 25 15:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tpL-0003Z9-2w; Mon, 25 Jun 2007 15:02:19 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I2tpK-0003YU-2W for sip-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 15:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2tpJ-0003YC-OV for sip@ietf.org; Mon, 25 Jun 2007 15:02:17 -0400 Received: from mail145.messagelabs.com ([216.82.245.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2tpH-0006AS-AD for sip@ietf.org; Mon, 25 Jun 2007 15:02:17 -0400 X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-145.messagelabs.com!1182798134!12914979!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [20.137.52.151] Received: (qmail 22598 invoked from network); 25 Jun 2007 19:02:14 -0000 Received: from amer-mta07.csc.com (HELO amer-mta07.csc.com) (20.137.52.151) by server-5.tower-145.messagelabs.com with AES256-SHA encrypted SMTP; 25 Jun 2007 19:02:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta07.csc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id l5PJ2QxE009329 for ; Mon, 25 Jun 2007 15:02:26 -0400 (EDT) In-Reply-To: To: "James M. Polk" Subject: Re: [Sip] New draft modifying RFC 4412 for Responses MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Mon, 25 Jun 2007 15:02:13 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 7.0.2FP1 HF180|March 29, 2007) at 06/25/2007 03:00:57 PM, Serialize complete at 06/25/2007 03:00:57 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1517075817==" Errors-To: sip-bounces@ietf.org This is a multipart message in MIME format. --===============1517075817== Content-Type: multipart/alternative; boundary="=_alternative 006891B585257305_=" This is a multipart message in MIME format. --=_alternative 006891B585257305_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SW4gd29ya2luZyBvbiBzcGVjaWZ5aW5nIGFuZCBkZXBsb3lpbmcgc3lzdGVtcyB0aGF0IHdpbGwg YWN0dWFsbHkgdXNlIHRoZSANClJQSCB3aXRoIHRoZSBldHMgYW5kIHdwcyBuYW1lc3BhY2VzLCB3 ZSBoYXZlIGZvdW5kIHNldmVyYWwgY29udGV4dHMgaW4gDQp3aGljaCB0aGUgUlBIICBvbiB0aGUg cmVzcG9uc2UgaXMgdmVyeSB1c2VmdWwuDQoNCjEpICAgICAgRXJyb3IgcmVwb3J0aW5nLiAgUkZD IDQ0MTIgZG9lcyBub3QgZ2l2ZSBjbGVhciBkaXJlY3Rpb24gb24gdGhlIA0KdHJlYXRtZW50IG9m IFJQSCB3aXRoIHN5bnRheCBlcnJvcnMgKG91dCBvZiByYW5nZSBwcmlvcml0eSB2YWx1ZXMsIA0K ZHVwbGljYXRlIG5hbWVzcGFjZXMsIGV0Yy4pICBXZSBoYXZlIGZvdW5kIHRoYXQgaW5jbHVkaW5n IHRoZSBSUEggaW4gdGhlIA0KNHh4IHJlc3BvbnNlcyBpcyB1c2VzZnVsIGluIGFkZHJlc3Npbmcg dGhlIGVycm9ycy4NCjIpICAgICAgSW4gb3VyIHN5c3RlbSwgd2Ugb2Z0ZW4gc2V0IHRoZSBldHMg IFJQSCAod2l0aCBkZWZhdWx0IHByaW9yaXR5KSANCmJhc2VkIG9uIHRoZSDigJxFVFMtRE7igJ3i gJxkaWFsZWQgbnVtYmVy4oCdIG9yIHVyaSwgYmVmb3JlIGF1dGhlbnRpY2F0aW9uIGFuZCANCmJl Zm9yZSBrbm93aW5nIHRoZSBjb3JyZWN0IHByaW9yaXR5IHZhbHVlLiAgSW5jbHVkaW5nIHRoZSBS UEggaW4gdGhlIA0KcmVzcG9uc2UgaXMgYSB1c2VmdWwgd2F5IG9mIGNvbnZleWluZyB0aGUgY29y cmVjdCBwcmlvcml0eSB2YWx1ZSBiYWNrIHRvIA0Kbm9kZXMgZWFybGllciBpbiB0aGUg4oCcY2Fs bCBmbG934oCdLg0KMykgICAgICBTaW1pbGFybHksIGlmIGFuIFJQIGFjdG9yIHJlY2VpdmVzIGEg U0lQIElOVklURSB3aXRoIHRoZSBFVFMtRE4sIA0KYnV0IG5vIFJQSCBpdCBtYXksIGFmdGVyIGF1 dGhlbnRpY2F0aW5nIHRoZSBjYWxsLCBpbmNsdWRlIFJQSCBpbiB0aGUgDQpyZXNwb25zZXMgaW4g b3JkZXIgdG8gaW5mb3JtICBub2RlcyBlYXJsaWVyIGluIHRoZSBjYWxsIGZsb3cgdGhhdCB0aGlz IGlzIA0KYSBwcmlvcml0eSBjYWxsLg0KNCkgICAgICBJZiB0aGUgUlBIIGlzIGJlaW5nIHVzZWQg dG8gcHJpb3JpdGl6ZSBwcm9jZXNzaW5nIChvZiBib3RoIA0KbWVzc2FnZXMgYW5kIHJlc3BvbnNl cykgaW4gdGhlIFNJUCB1c2VyIGFnZW50LCBpbmNsdWRpbmcgdGhlIFJQSCBpbiB0aGUgDQpyZXNw b25zZSBhbGxvd3MgdGhlIHJlY2VpdmluZyBSUCBhY3RvciB0byBnaXZlIHRoZSByZXNwb25zZSDi gJxFVFMgDQp0cmVhdG1lbnTigJ0gYmVmb3JlIGNoZWNraW5nIG9uIHRoZSDigJxzdGF0ZeKAnSBv ZiB0aGUgY2FsbC4gIFRoaXMgaXMgDQpwYXJ0aWN1bGFybHkgcmVsZXZhbnQgd2hlbiB0aGUgUlAg YWN0b3IgaXRzZWxmIGlzIGNvbmdlc3RlZC4NCg0KSmFuZXQNCg0KDQoiSmFtZXMgTS4gUG9sayIg PGptcG9sa0BjaXNjby5jb20+IHdyb3RlIG9uIDA2LzE2LzIwMDcgMDU6MTM6MzcgUE06DQoNCj4g U0lQIFdHDQo+IA0KPiBIZXJlIGlzIGEgbmV3IElEIEkndmUgd3JpdHRlbiBiZWNhdXNlIG9mIGlt cGxlbWVudGF0aW9uIA0KPiBjb25zaWRlcmF0aW9ucyB0byBhbGxvdyBhIFNJUCBSZXNvdXJjZS1Q cmlvcml0eSBoZWFkZXIgKFJQSCkgaW4gDQo+IHJlc3BvbnNlcywgd2hpY2ggUkZDIDQ0MTIgY3Vy cmVudGx5IGRpc2FsbG93cywgYXNzdW1pbmcgb25seSB0aGF0IA0KPiBzdGF0ZWZ1bCBkZXZpY2Vz IHdpbGwgdXNlIFJQSC4gIFRoZXJlIGhhdmUgYmVlbiBtYW55IHJlcXVlc3RzIHRvIGhhdmUgDQo+ IHRoaXMgIm9ubHkgc3RhdGVmdWwgZGV2aWNlcyIgcmVzdHJpY3Rpb24gcmVsYXhlZCwgaW4gY2Vy dGFpbiANCj4gc2NlbmFyaW9zLiAgVGhpcyBJRCBkb2VzIHRoaXMsIGFuZCBwcm9wb3NlcyBob3cg SUFOQSBpcyBjaGFuZ2VkIA0KPiBhY2NvcmRpbmdseSB3cnQgUlBILiAgVGhpcyBJRCBkb2VzIG5v dGhpbmcgZWxzZS4NCj4gDQo+IENvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCj4gDQo+ID5BIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMNCj4gPmRpcmVjdG9yaWVzLg0KPiA+DQo+ID4gICAgICAgICBUaXRsZSAgICAgICAgICAg OiBBbGxvd2luZyBTSVAgUmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyIGluIA0KPiA+IFNJUCBSZXNw b25zZXMNCj4gPiAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IEouIFBvbGsNCj4gPiAgICAgICAg IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LXBvbGstc2lwLXJwaC1pbi1yZXNwb25zZXMtMDAudHh0 DQo+ID4gICAgICAgICBQYWdlcyAgICAgICAgICAgOiA2DQo+ID4gICAgICAgICBEYXRlICAgICAg ICAgICAgOiAyMDA3LTYtMTUNCj4gPg0KPiA+ICAgIFRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkgUmVzb3VyY2UgUHJpb3JpdHkgSGVhZGVyDQo+ID4gICAgKFJQSCksIGluIGl0 cyBjdXJyZW50IGZvcm0sIGlzIGlnbm9yZWQgaW4gU0lQIHJlc3BvbnNlcy4gIFRoaXMgd2FzIA0K YQ0KPiA+ICAgIGRlc2lnbiBjaG9pY2UgZHVyaW5nIFJGQyA0NDEyJ3MgZGV2ZWxvcG1lbnQuIFRo aXMgaXMgbm93IGNvbnNpZGVyZWQNCj4gPiAgICBhIGJhZCBkZXNpZ24gY2hvaWNlIGluIGNlcnRh aW4gc2NlbmFyaW9zLiAgVGhpcyBkb2N1bWVudCBjb3JyZWN0cw0KPiA+ICAgIFJGQyA0NDEyJ3Mg Y29tbXVuaWNhdGlvbnMgbW9kZWwgYnkgb3B0aW9uYWxseSBhbGxvd2luZyBhIFNJUCBzZXJ2ZXIN Cj4gPiAgICBvciB1c2VyIGFnZW50IGNsaWVudCB0byBwcm9jZXNzIHRoZSBSZXNvdXJjZS1Qcmlv cml0eSBIZWFkZXIgaW4gYQ0KPiA+ICAgIHJlc3BvbnNlLg0KPiA+DQo+ID5BIFVSTCBmb3IgdGhp cyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gDQo+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMC50eHQNCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTaXAgbWFp bGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCj4g VGhpcyBsaXN0IGlzIGZvciBORVcgZGV2ZWxvcG1lbnQgb2YgdGhlIGNvcmUgU0lQIFByb3RvY29s DQo+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVlc3Rpb25zIG9u IGN1cnJlbnQgc2lwDQo+IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRz IG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCg0K --=_alternative 006891B585257305_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JbiB3b3JraW5nIG9uIHNw ZWNpZnlpbmcgYW5kDQpkZXBsb3lpbmcgc3lzdGVtcyB0aGF0IHdpbGwgYWN0dWFsbHkgdXNlIHRo ZSBSUEggd2l0aCB0aGUgZXRzIGFuZCB3cHMgbmFtZXNwYWNlcywNCndlIGhhdmUgZm91bmQgc2V2 ZXJhbCBjb250ZXh0cyBpbiB3aGljaCB0aGUgUlBIICZuYnNwO29uIHRoZSByZXNwb25zZSBpcw0K dmVyeSB1c2VmdWwuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjEpICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Vycm9yDQpyZXBvcnRpbmcu ICZuYnNwO1JGQyA0NDEyIGRvZXMgbm90IGdpdmUgY2xlYXIgZGlyZWN0aW9uIG9uIHRoZSB0cmVh dG1lbnQNCm9mIFJQSCB3aXRoIHN5bnRheCBlcnJvcnMgKG91dCBvZiByYW5nZSBwcmlvcml0eSB2 YWx1ZXMsIGR1cGxpY2F0ZSBuYW1lc3BhY2VzLA0KZXRjLikgJm5ic3A7V2UgaGF2ZSBmb3VuZCB0 aGF0IGluY2x1ZGluZyB0aGUgUlBIIGluIHRoZSAmbmJzcDs0eHggcmVzcG9uc2VzDQppcyB1c2Vz ZnVsIGluIGFkZHJlc3NpbmcgdGhlIGVycm9ycy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+MikgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW4NCm91 ciBzeXN0ZW0sIHdlIG9mdGVuIHNldCB0aGUgZXRzICZuYnNwO1JQSCAod2l0aCBkZWZhdWx0IHBy aW9yaXR5KSAmbmJzcDtiYXNlZA0Kb24gdGhlIOKAnEVUUy1ETuKAneKAnGRpYWxlZCBudW1iZXLi gJ0gb3IgdXJpLCBiZWZvcmUgYXV0aGVudGljYXRpb24gYW5kIGJlZm9yZQ0Ka25vd2luZyB0aGUg Y29ycmVjdCBwcmlvcml0eSB2YWx1ZS4gJm5ic3A7SW5jbHVkaW5nIHRoZSBSUEggaW4gdGhlIHJl c3BvbnNlDQppcyBhIHVzZWZ1bCB3YXkgb2YgY29udmV5aW5nIHRoZSBjb3JyZWN0IHByaW9yaXR5 IHZhbHVlIGJhY2sgdG8gbm9kZXMgZWFybGllcg0KaW4gdGhlIOKAnGNhbGwgZmxvd+KAnS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+MykgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7U2ltaWxhcmx5LA0KaWYgYW4gUlAgYWN0b3IgcmVjZWl2ZXMgYSBT SVAgSU5WSVRFIHdpdGggdGhlIEVUUy1ETiwgYnV0IG5vIFJQSCBpdCBtYXksDQphZnRlciBhdXRo ZW50aWNhdGluZyB0aGUgY2FsbCwgaW5jbHVkZSBSUEggaW4gdGhlIHJlc3BvbnNlcyBpbiBvcmRl ciB0bw0KaW5mb3JtICZuYnNwO25vZGVzIGVhcmxpZXIgaW4gdGhlIGNhbGwgZmxvdyB0aGF0IHRo aXMgaXMgYSBwcmlvcml0eSBjYWxsLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj40KSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJZg0KdGhlIFJQSCBp cyBiZWluZyB1c2VkIHRvIHByaW9yaXRpemUgcHJvY2Vzc2luZyAob2YgYm90aCBtZXNzYWdlcyBh bmQgcmVzcG9uc2VzKQ0KaW4gdGhlIFNJUCB1c2VyIGFnZW50LCBpbmNsdWRpbmcgdGhlIFJQSCBp biB0aGUgcmVzcG9uc2UgYWxsb3dzIHRoZSByZWNlaXZpbmcNClJQIGFjdG9yIHRvIGdpdmUgdGhl IHJlc3BvbnNlIOKAnEVUUyB0cmVhdG1lbnTigJ0gYmVmb3JlIGNoZWNraW5nIG9uIHRoZQ0K4oCc c3RhdGXigJ0gb2YgdGhlIGNhbGwuICZuYnNwO1RoaXMgaXMgcGFydGljdWxhcmx5IHJlbGV2YW50 IHdoZW4gdGhlIFJQDQphY3RvciBpdHNlbGYgaXMgY29uZ2VzdGVkLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQ8YnI+DQo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mcXVvdDtKYW1lcyBNLiBQb2xrJnF1b3Q7ICZsdDtqbXBv bGtAY2lzY28uY29tJmd0Ow0Kd3JvdGUgb24gMDYvMTYvMjAwNyAwNToxMzozNyBQTTo8YnI+DQo8 YnI+DQomZ3Q7IFNJUCBXRzxicj4NCiZndDsgPGJyPg0KJmd0OyBIZXJlIGlzIGEgbmV3IElEIEkn dmUgd3JpdHRlbiBiZWNhdXNlIG9mIGltcGxlbWVudGF0aW9uIDxicj4NCiZndDsgY29uc2lkZXJh dGlvbnMgdG8gYWxsb3cgYSBTSVAgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyIChSUEgpIGluIDxi cj4NCiZndDsgcmVzcG9uc2VzLCB3aGljaCBSRkMgNDQxMiBjdXJyZW50bHkgZGlzYWxsb3dzLCBh c3N1bWluZyBvbmx5IHRoYXQNCjxicj4NCiZndDsgc3RhdGVmdWwgZGV2aWNlcyB3aWxsIHVzZSBS UEguICZuYnNwO1RoZXJlIGhhdmUgYmVlbiBtYW55IHJlcXVlc3RzDQp0byBoYXZlIDxicj4NCiZn dDsgdGhpcyAmcXVvdDtvbmx5IHN0YXRlZnVsIGRldmljZXMmcXVvdDsgcmVzdHJpY3Rpb24gcmVs YXhlZCwgaW4gY2VydGFpbg0KPGJyPg0KJmd0OyBzY2VuYXJpb3MuICZuYnNwO1RoaXMgSUQgZG9l cyB0aGlzLCBhbmQgcHJvcG9zZXMgaG93IElBTkEgaXMgY2hhbmdlZA0KPGJyPg0KJmd0OyBhY2Nv cmRpbmdseSB3cnQgUlBILiAmbmJzcDtUaGlzIElEIGRvZXMgbm90aGluZyBlbHNlLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDtBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7ICZndDtkaXJlY3Rvcmllcy48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDogQWxsb3dpbmcgU0lQIFJlc291cmNlIFBy aW9yaXR5IEhlYWRlciBpbiA8YnI+DQomZ3Q7ICZndDsgU0lQIFJlc3BvbnNlczxicj4NCiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDoNCkouIFBvbGs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEZpbGVuYW1lICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzoNCmRyYWZ0LXBvbGstc2lw LXJwaC1pbi1yZXNwb25zZXMtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyA6IDY8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7OiAyMDA3LTYtMTU8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkgUmVzb3VyY2UgUHJpb3JpdHkNCkhlYWRlcjxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7KFJQSCksIGluIGl0cyBjdXJyZW50IGZvcm0sIGlzIGlnbm9yZWQgaW4gU0lQIHJl c3BvbnNlcy4NCiZuYnNwO1RoaXMgd2FzIGE8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2Rl c2lnbiBjaG9pY2UgZHVyaW5nIFJGQyA0NDEyJ3MgZGV2ZWxvcG1lbnQuIFRoaXMNCmlzIG5vdyBj b25zaWRlcmVkPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDthIGJhZCBkZXNpZ24gY2hvaWNl IGluIGNlcnRhaW4gc2NlbmFyaW9zLiAmbmJzcDtUaGlzDQpkb2N1bWVudCBjb3JyZWN0czxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UkZDIDQ0MTIncyBjb21tdW5pY2F0aW9ucyBtb2RlbCBi eSBvcHRpb25hbGx5IGFsbG93aW5nDQphIFNJUCBzZXJ2ZXI8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO29yIHVzZXIgYWdlbnQgY2xpZW50IHRvIHByb2Nlc3MgdGhlIFJlc291cmNlLVByaW9y aXR5DQpIZWFkZXIgaW4gYTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cmVzcG9uc2UuPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQg aXM6PGJyPg0KJmd0OyAmZ3Q7aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcG9say1zaXAtcnBoLWluLXJlc3BvbnNlcy0wMC50eHQ8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgU2lwIG1haWxpbmcgbGlzdCAmbmJzcDtodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXA8YnI+DQomZ3Q7IFRoaXMgbGlzdCBpcyBmb3IgTkVXIGRldmVs b3BtZW50IG9mIHRoZSBjb3JlIFNJUCBQcm90b2NvbDxicj4NCiZndDsgVXNlIHNpcC1pbXBsZW1l bnRvcnNAY3MuY29sdW1iaWEuZWR1IGZvciBxdWVzdGlvbnMgb24gY3VycmVudCBzaXA8YnI+DQom Z3Q7IFVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBs aWNhdGlvbiBvZiBzaXA8YnI+DQo8L3R0PjwvZm9udD4NCg== --=_alternative 006891B585257305_=-- --===============1517075817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1517075817==-- From sip-bounces@ietf.org Tue Jun 26 05:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37n7-0001u3-9n; Tue, 26 Jun 2007 05:56:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I37n5-0001tt-Nd for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 05:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I37n5-0001tl-E4; Tue, 26 Jun 2007 05:56:55 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I37me-0008VD-Q3; Tue, 26 Jun 2007 05:56:55 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5b4680f701; Tue, 26 Jun 2007 18:07:57 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb24679e4ba; Thr, 21 Jun 2007 09:03:41 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 21 Jun 2007 09:03:41 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYU-0007lD-7x; Wed, 20 Jun 2007 20:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYQ-0007hQ-EV; Wed, 20 Jun 2007 20:29:42 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1AYP-0002d6-5C; Wed, 20 Jun 2007 20:29:42 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 08838D6BB0; Wed, 20 Jun 2007 17:28:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070621002824.08838D6BB0@bosco.isi.edu> Date: Wed, 20 Jun 2007 17:28:24 -0700 (PDT) X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: rfc-editor@rfc-editor.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.0 (++) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4916 on Connected Identity in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4916 Title: Connected Identity in the Session Initiation Protocol (SIP) Author: J. Elwell Status: Standards Track Date: June 2007 Mailbox: john.elwell@siemens.com Pages: 24 Characters: 42924 Updates: RFC3261 See-Also: I-D Tag: draft-ietf-sip-connected-identity-05.txt URL: http://www.rfc-editor.org/rfc/rfc4916.txt This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 11:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Cnt-0003Ve-S9; Tue, 26 Jun 2007 11:18:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3Cnq-0003VA-8F for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 11:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Cnp-0003V2-Ut for sip@ietf.org; Tue, 26 Jun 2007 11:18:01 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Cne-0002Df-4s for sip@ietf.org; Tue, 26 Jun 2007 11:18:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5QFHREr017002; Tue, 26 Jun 2007 18:17:40 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 18:17:30 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 18:17:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 26 Jun 2007 18:17:29 +0300 Message-ID: In-Reply-To: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8AKMEtdw References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> From: To: , X-OriginalArrivalTime: 26 Jun 2007 15:17:30.0608 (UTC) FILETIME=[1D1C2700:01C7B805] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I think certificate authentication would be a valuable addition to SIP's arsenal of authentication methods, to better support environments where certificates can be deployed, in a similar way as RFCs 3310 and 4169 were done to support SIM-based authentication. So, I would support adding the topic as a charter item and adopting the requirements draft as a WG item as the starting point. =20 Markus >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 >Sent: 13 June, 2007 18:58 >To: IETF SIP List >Subject: [Sip] Certificate authentication in SIP > >(As WG chair) > >http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat >e-auth-03 >.txt=20 > >Describes a set of requirements for: > > This document defines requirements for adding certificate > authentication to the Session Initiation Protocol (SIP). This > document is being presented with the intention of providing clear > requirements to any potential solutions specifying certificate > authentication within SIP networks. Supporting certificate > authentication in SIP would provide strong authentication and > increase the types of possible deployment scenarios. > >(Before we go any further, please forget all about the=20 >solutions document - that comes later and we are not dealing=20 >with it now) > >We need to decide whether there is support for a body of work=20 >in this area, and therefore whether we should charter some=20 >requirements work in the SIP WG. > >(Because this is security related we have agreed that SIP does=20 >the requirements drafting and not SIPPING) > >So can I hear opinions of the WG on: > >- whether this represents a problem space that the working group >should draft requirements on? > >- whether the problem space exists but is something slightly >different, and if so what is that problem space? > >- whether there is a more general problem that the security area >should be addressing, rather than the SIP group addressing=20 >something specific? > >- based on your answers to the first three questions, whether this >draft is essentially in the right direction to be adopted as=20 >the WG draft assuming we create the charter item, or whether=20 >we need to seek some other input draft? > >- and finally, whether (assuming we go ahead with this work) there >is any work in any other IETF WG that we should take account of? > > >Regards > >Keith > > > >Regards > >Keith > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 11:34:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D3S-000126-On; Tue, 26 Jun 2007 11:34:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3D3R-000121-2L for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 11:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D3Q-00011s-Ox for sip@ietf.org; Tue, 26 Jun 2007 11:34:08 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3D2l-0006Ha-06 for sip@ietf.org; Tue, 26 Jun 2007 11:34:08 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1182871563!21880338!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 12843 invoked from network); 26 Jun 2007 15:26:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-120.messagelabs.com with SMTP; 26 Jun 2007 15:26:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l5QFQ2M4026288 for ; Tue, 26 Jun 2007 11:26:03 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.13.8/8.13.8) with ESMTP id l5QFPwDx026207 for ; Tue, 26 Jun 2007 11:25:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 26 Jun 2007 10:25:57 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246E099@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8AKMEtdwAACNU/A= References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> From: "DOLLY, MARTIN C, ATTLABS" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hello, Agreed, that this would be a valuable option/alternative to have. Martin=20 -----Original Message----- From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 Sent: Tuesday, June 26, 2007 11:17 AM To: drage@alcatel-lucent.com; sip@ietf.org Subject: RE: [Sip] Certificate authentication in SIP Hi, I think certificate authentication would be a valuable addition to SIP's arsenal of authentication methods, to better support environments where certificates can be deployed, in a similar way as RFCs 3310 and 4169 were done to support SIM-based authentication. So, I would support adding the topic as a charter item and adopting the requirements draft as a WG item as the starting point. =20 Markus >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 >Sent: 13 June, 2007 18:58 >To: IETF SIP List >Subject: [Sip] Certificate authentication in SIP > >(As WG chair) > >http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat >e-auth-03 >.txt=20 > >Describes a set of requirements for: > > This document defines requirements for adding certificate > authentication to the Session Initiation Protocol (SIP). This > document is being presented with the intention of providing clear > requirements to any potential solutions specifying certificate > authentication within SIP networks. Supporting certificate > authentication in SIP would provide strong authentication and > increase the types of possible deployment scenarios. > >(Before we go any further, please forget all about the=20 >solutions document - that comes later and we are not dealing=20 >with it now) > >We need to decide whether there is support for a body of work=20 >in this area, and therefore whether we should charter some=20 >requirements work in the SIP WG. > >(Because this is security related we have agreed that SIP does=20 >the requirements drafting and not SIPPING) > >So can I hear opinions of the WG on: > >- whether this represents a problem space that the working group >should draft requirements on? > >- whether the problem space exists but is something slightly >different, and if so what is that problem space? > >- whether there is a more general problem that the security area >should be addressing, rather than the SIP group addressing=20 >something specific? > >- based on your answers to the first three questions, whether this >draft is essentially in the right direction to be adopted as=20 >the WG draft assuming we create the charter item, or whether=20 >we need to seek some other input draft? > >- and finally, whether (assuming we go ahead with this work) there >is any work in any other IETF WG that we should take account of? > > >Regards > >Keith > > > >Regards > >Keith > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip=20 >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 11:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D5J-0001yQ-M2; Tue, 26 Jun 2007 11:36:05 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3D5I-0001yI-57 for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 11:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3D5H-0001yA-Rx for sip@ietf.org; Tue, 26 Jun 2007 11:36:03 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3D4V-0006WZ-KB for sip@ietf.org; Tue, 26 Jun 2007 11:36:03 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5QFZDp00188 for ; Tue, 26 Jun 2007 15:35:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 26 Jun 2007 10:35:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11057BB7@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Acet068oaXVT7Q2dQbOhofCJDIAJ8AKMEtdwAADi3TA= References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> From: "Francois Audet" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Same here.=20 I think the document needs a bit of work, but it's a good start. > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]=20 > Sent: Tuesday, June 26, 2007 08:17 > To: drage@alcatel-lucent.com; sip@ietf.org > Subject: RE: [Sip] Certificate authentication in SIP >=20 > Hi, >=20 > I think certificate authentication would be a valuable=20 > addition to SIP's arsenal of authentication methods, to=20 > better support environments where certificates can be=20 > deployed, in a similar way as RFCs 3310 and 4169 were done to=20 > support SIM-based authentication. >=20 > So, I would support adding the topic as a charter item and=20 > adopting the > requirements draft as a WG item as the starting point. =20 >=20 > Markus >=20 >=20 > >-----Original Message----- > >From: ext DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >Sent: 13 June, 2007 18:58 > >To: IETF SIP List > >Subject: [Sip] Certificate authentication in SIP > > > >(As WG chair) > > > >http://www.ietf.org/internet-drafts/draft-dotson-sip-certificat > >e-auth-03 > >.txt > > > >Describes a set of requirements for: > > > > This document defines requirements for adding certificate > > authentication to the Session Initiation Protocol (SIP). This > > document is being presented with the intention of providing clear > > requirements to any potential solutions specifying certificate > > authentication within SIP networks. Supporting certificate > > authentication in SIP would provide strong authentication and > > increase the types of possible deployment scenarios. > > > >(Before we go any further, please forget all about the solutions=20 > >document - that comes later and we are not dealing with it now) > > > >We need to decide whether there is support for a body of=20 > work in this=20 > >area, and therefore whether we should charter some=20 > requirements work in=20 > >the SIP WG. > > > >(Because this is security related we have agreed that SIP does the=20 > >requirements drafting and not SIPPING) > > > >So can I hear opinions of the WG on: > > > >- whether this represents a problem space that the working group > >should draft requirements on? > > > >- whether the problem space exists but is something slightly > >different, and if so what is that problem space? > > > >- whether there is a more general problem that the security area > >should be addressing, rather than the SIP group addressing something=20 > >specific? > > > >- based on your answers to the first three questions, whether this > >draft is essentially in the right direction to be adopted as the WG=20 > >draft assuming we create the charter item, or whether we=20 > need to seek=20 > >some other input draft? > > > >- and finally, whether (assuming we go ahead with this work) there > >is any work in any other IETF WG that we should take account of? > > > > > >Regards > > > >Keith > > > > > > > >Regards > > > >Keith > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use=20 > >sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 19:14:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KFH-0003oi-OK; Tue, 26 Jun 2007 19:14:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3KFG-0003oc-Hn for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 19:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KFG-0003oU-8K for sip@ietf.org; Tue, 26 Jun 2007 19:14:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3KEv-0002VY-Ik for sip@ietf.org; Tue, 26 Jun 2007 19:14:50 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2007 15:58:32 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADA5gUarR7O6h2dsb2JhbACPJwEBAQgOLA X-IronPort-AV: i="4.16,464,1175497200"; d="scan'208"; a="164319247:sNHT13952443689" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5QMwWk7017907; Tue, 26 Jun 2007 15:58:32 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l5QMwVw5021757; Tue, 26 Jun 2007 22:58:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:58:32 -0700 Received: from [128.107.110.137] ([128.107.110.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:58:30 -0700 Message-ID: <46819A15.9030704@cisco.com> Date: Tue, 26 Jun 2007 18:58:29 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> In-Reply-To: <46819819.5080107@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2007 22:58:30.0448 (UTC) FILETIME=[83A8CB00:01C7B845] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3768; t=1182898712; x=1183762712; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=EzM7HTxo+Sv8O1MyTKXLMAxLBamCXsB8e/bZbFEuVJI=; b=aOZSYYumzmrTYHDRDziqh880Axg8NFfHjrOREd5WCQ5brIpnXJMOoUklLN1Bn2b03Q7n11ww FX8twPMhtIkQA9FDt53UUVf/xqJU7+p87s8NnuaNco+SQ53xCTwPufnx; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hit send too quickly. An alternate solution here is to just use TLS between the client and its next SIP hop. If thats the registrar, great, we're done. If its an intermediate proxy - then the intermediate proxy has basically done the authentication and can use RFC 4474 or 3325 to convey that authenticated identity to the registrar. If you are worried about cases of local proxies in untrusted networks, separate from your home proxy - well there are tons of problems in that model and its something we need to discourage. If you step back a moment - it seems wrong to me that we are going to have our clients implement TLS, which supports client authentication with certificates, but then tell them that they need to ALSO implement something entirely different to accomplish the same thing. -Jonathan R. Jonathan Rosenberg wrote: > Well, I'm going to be contrarian here. I'm not convinced that this is > needed. > > I think certificate based authentication is a great idea. However, I am > not sure I understand why TLS is not an appropriate solution. > > DRAGE, Keith (Keith) wrote: > >> (As WG chair) >> >> http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 >> .txt >> Describes a set of requirements for: >> >> This document defines requirements for adding certificate >> authentication to the Session Initiation Protocol (SIP). This >> document is being presented with the intention of providing clear >> requirements to any potential solutions specifying certificate >> authentication within SIP networks. Supporting certificate >> authentication in SIP would provide strong authentication and >> increase the types of possible deployment scenarios. >> >> (Before we go any further, please forget all about the solutions >> document - that comes later and we are not dealing with it now) >> >> We need to decide whether there is support for a body of work in this >> area, and therefore whether we should charter some requirements work in >> the SIP WG. >> >> (Because this is security related we have agreed that SIP does the >> requirements drafting and not SIPPING) >> >> So can I hear opinions of the WG on: >> >> - whether this represents a problem space that the working group >> should draft requirements on? >> >> - whether the problem space exists but is something slightly >> different, and if so what is that problem space? >> >> - whether there is a more general problem that the security area >> should be addressing, rather than the SIP group addressing something >> specific? >> >> - based on your answers to the first three questions, whether this >> draft is essentially in the right direction to be adopted as the WG >> draft assuming we create the charter item, or whether we need to seek >> some other input draft? >> >> - and finally, whether (assuming we go ahead with this work) there >> is any work in any other IETF WG that we should take account of? >> >> >> Regards >> >> Keith >> >> >> >> Regards >> >> Keith >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 26 19:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KRe-0004SF-HE; Tue, 26 Jun 2007 19:27:38 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3KRd-0004S9-4g for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 19:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KRc-0004S1-RM for sip@ietf.org; Tue, 26 Jun 2007 19:27:36 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3KQv-0006qs-IQ for sip@ietf.org; Tue, 26 Jun 2007 19:27:36 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2007 15:50:02 -0700 X-IronPort-AV: i="4.16,465,1175497200"; d="scan'208"; a="172624149:sNHT6667263666" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5QMo2r7027737; Tue, 26 Jun 2007 15:50:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5QMo2mo021840; Tue, 26 Jun 2007 22:50:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:50:06 -0700 Received: from [128.107.110.137] ([128.107.110.137]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jun 2007 15:50:01 -0700 Message-ID: <46819819.5080107@cisco.com> Date: Tue, 26 Jun 2007 18:50:01 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2007 22:50:01.0837 (UTC) FILETIME=[5480E9D0:01C7B844] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2829; t=1182898202; x=1183762202; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=vlLCHzNeDA12wCxBk7GNHho7Z3KEK7ODqt13NanIui4=; b=gzHn7k/RbeRfr45joUjACfHTUlhv0R9VrEI42JkhMrMVErt3p//Xq6lhXhb5jYsWlYYmsaC3 /rwo1cu+pei4lsGSaN/7MDUBa6ez4mmGR2sYJIb5he5E0CXrZQ/BzBIV; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Well, I'm going to be contrarian here. I'm not convinced that this is needed. I think certificate based authentication is a great idea. However, I am not sure I understand why TLS is not an appropriate solution. DRAGE, Keith (Keith) wrote: > (As WG chair) > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 > .txt > > Describes a set of requirements for: > > This document defines requirements for adding certificate > authentication to the Session Initiation Protocol (SIP). This > document is being presented with the intention of providing clear > requirements to any potential solutions specifying certificate > authentication within SIP networks. Supporting certificate > authentication in SIP would provide strong authentication and > increase the types of possible deployment scenarios. > > (Before we go any further, please forget all about the solutions > document - that comes later and we are not dealing with it now) > > We need to decide whether there is support for a body of work in this > area, and therefore whether we should charter some requirements work in > the SIP WG. > > (Because this is security related we have agreed that SIP does the > requirements drafting and not SIPPING) > > So can I hear opinions of the WG on: > > - whether this represents a problem space that the working group > should draft requirements on? > > - whether the problem space exists but is something slightly > different, and if so what is that problem space? > > - whether there is a more general problem that the security area > should be addressing, rather than the SIP group addressing something > specific? > > - based on your answers to the first three questions, whether this > draft is essentially in the right direction to be adopted as the WG > draft assuming we create the charter item, or whether we need to seek > some other input draft? > > - and finally, whether (assuming we go ahead with this work) there > is any work in any other IETF WG that we should take account of? > > > Regards > > Keith > > > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Tue Jun 26 20:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LEg-00087S-6r; Tue, 26 Jun 2007 20:18:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3LEe-00086S-8v for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 20:18:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3LEd-00086K-Vj for sip@ietf.org; Tue, 26 Jun 2007 20:18:15 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3LE3-0007JO-Ee for sip@ietf.org; Tue, 26 Jun 2007 20:18:15 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5R0HZI28056; Wed, 27 Jun 2007 00:17:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Tue, 26 Jun 2007 19:17:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF110A93E0@zrc2hxm0.corp.nortel.com> In-Reply-To: <46819819.5080107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4SZ3e8lof313nQL+HJmXxy3HoUgABsPtA References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> From: "Francois Audet" To: "Jonathan Rosenberg" , "DRAGE, Keith (Keith)" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Funny: i was assuming that we were talking about mutual TLS here... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 > Sent: Tuesday, June 26, 2007 15:50 > To: DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: Re: [Sip] Certificate authentication in SIP >=20 > Well, I'm going to be contrarian here. I'm not convinced that=20 > this is needed. >=20 > I think certificate based authentication is a great idea.=20 > However, I am not sure I understand why TLS is not an=20 > appropriate solution. >=20 > DRAGE, Keith (Keith) wrote: >=20 > > (As WG chair) > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth- > > 03 > > .txt > >=20 > > Describes a set of requirements for: > >=20 > > This document defines requirements for adding certificate > > authentication to the Session Initiation Protocol (SIP). This > > document is being presented with the intention of providing clear > > requirements to any potential solutions specifying certificate > > authentication within SIP networks. Supporting certificate > > authentication in SIP would provide strong authentication and > > increase the types of possible deployment scenarios. > >=20 > > (Before we go any further, please forget all about the solutions=20 > > document - that comes later and we are not dealing with it now) > >=20 > > We need to decide whether there is support for a body of=20 > work in this=20 > > area, and therefore whether we should charter some=20 > requirements work=20 > > in the SIP WG. > >=20 > > (Because this is security related we have agreed that SIP does the=20 > > requirements drafting and not SIPPING) > >=20 > > So can I hear opinions of the WG on: > >=20 > > - whether this represents a problem space that the working group > > should draft requirements on? > >=20 > > - whether the problem space exists but is something slightly > > different, and if so what is that problem space? > >=20 > > - whether there is a more general problem that the security area > > should be addressing, rather than the SIP group addressing=20 > something=20 > > specific? > >=20 > > - based on your answers to the first three questions, whether this > > draft is essentially in the right direction to be adopted as the WG=20 > > draft assuming we create the charter item, or whether we=20 > need to seek=20 > > some other input draft? > >=20 > > - and finally, whether (assuming we go ahead with this work) there > > is any work in any other IETF WG that we should take account of? > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol Use=20 > sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 21:34:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3MQU-0006ix-De; Tue, 26 Jun 2007 21:34:34 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3MQS-0006is-N3 for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 21:34:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3MQS-0006ik-Db for sip@ietf.org; Tue, 26 Jun 2007 21:34:32 -0400 Received: from szinterscan.utstar.com.cn ([210.21.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3MQF-0001cm-1M for sip@ietf.org; Tue, 26 Jun 2007 21:34:32 -0400 Received: from szsmtp.utstar.com.cn ([172.19.224.12]) by szinterscan.utstar.com.cn with InterScan Messaging Security Suite; Wed, 27 Jun 2007 09:44:40 +0800 Received: from SZMAIL11.cn.utstarcom.com (szmail03.cn.utstarcom.com [172.19.30.102] (may be forged)) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with ESMTP id l5R1WPr25568; Wed, 27 Jun 2007 09:32:25 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: =?gb2312?B?tPC4tDogW1NpcF0gQ291bGQgYSBVQSBpc3N1ZSBhIG5ldyBOT1RJRg==?= =?gb2312?B?WSBiZWZvcmUgdGhlcHJldmlvdXNOT1RJRll0cmFuc2FjdGlvbiBoYXMgY28=?= =?gb2312?B?bXBsZXRlZD8=?= Date: Wed, 27 Jun 2007 09:32:25 +0800 Message-ID: In-Reply-To: <003701c7b469$4aa26170$e31c550a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Could a UA issue a new NOTIFY before thepreviousNOTIFYtransaction has completed? Thread-Index: Ace0aXtf731A11W6T5CafYAj9Xe5hwD8EiRQ References: <75B2A84D9323BC4CA3977CF378CE75EB036757B9@xmb-sjc-21e.amer.cisco.com><467B0E61.3090101@cisco.com> <003701c7b469$4aa26170$e31c550a@china.huawei.com> From: "Gerald Yan" To: "Bruce Qi" , "SIP" , "Paul Kyzivat" X-Spam-Score: 0.5 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Peili Xu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This issue may occur in the case of issuing NOTIFY to multiple SUBSCRIBE = or REFER in a dialog. Best regards Gerald Tel:86-755-26952899 34617 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Bruce Qi [mailto:qibj@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2007-06-22 9:05 =CA=D5=BC=FE=C8=CB: SIP; Paul Kyzivat =B3=AD=CB=CD: Peili Xu =D6=F7=CC=E2: Re: [Sip] Could a UA issue a new NOTIFY before = thepreviousNOTIFYtransaction has completed? Hi Paul: Is This issue belong to the internal implementation of SIP = production? Beacuse I think there are many similar issues in the = development of SIP production. Thanks and Regards Burce Qi ----- Original Message -----=20 From: "Paul Kyzivat" To: "Arunachalam Venkatraman (arunvenk)" Cc: ; "yan" Sent: Friday, June 22, 2007 7:48 AM Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous = NOTIFY transaction has completed? >=20 >=20 > Arunachalam Venkatraman (arunvenk) wrote: >> However, if you are using UDP and if the data in the second NOTIFY is = >> additive to and not replacing the prior NOTIFY, you may run into the=20 >> issue of out-of-sequence delivery. >=20 > This can be a problem even when using TCP if there are proxies in the > path. There is no requirement for proxies to deliver messages in the > order they receive them. >=20 > Paul >=20 >> = ------------------------------------------------------------------------ >>=20 >> *From:* Robert Sparks [mailto:rjsparks@nostrum.com] >> *Sent:* Wednesday, June 20, 2007 12:18 PM >> *To:* yan >> *Cc:* sip@ietf.org >> *Subject:* Re: [Sip] Could a UA issue a new NOTIFY before the = previous=20 >> NOTIFYtransaction has completed? >>=20 >> =20 >>=20 >> Generally speaking, yes. >>=20 >> =20 >>=20 >> An individual event package may restrict that behavior though. >>=20 >> =20 >>=20 >> RjS >>=20 >> =20 >>=20 >> On Jun 15, 2007, at 12:16 PM, yan wrote: >>=20 >>=20 >>=20 >> hi: >>=20 >> Could anyone answer me the question: >>=20 >> Can a UA issue a new NOTIFY before the previous NOTIFY transaction = has=20 >> completed? >>=20 >> thx >>=20 >> =20 >>=20 >> yan >>=20 >> =20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> 150 =CD=F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 = =D3=CE=A3=AC=C4=E3 =B2=BB =CA=D4 =CA=D4 =C2=F0 =A3=BF=20 >> >>=20 >> _______________________________________________ >>=20 >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>=20 >> This list is for NEW development of the core SIP Protocol >>=20 >> Use sip-implementors@cs.columbia.edu=20 >> for questions on current = sip >>=20 >> Use sipping@ietf.org for new developments = on=20 >> the application of sip >>=20 >> =20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 22:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NQ7-0006YM-2O; Tue, 26 Jun 2007 22:38:15 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3NQ5-0006YF-MR for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 22:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3NQ5-0006Y7-CW for sip@ietf.org; Tue, 26 Jun 2007 22:38:13 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3NP2-0006px-UP for sip@ietf.org; Tue, 26 Jun 2007 22:38:13 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK900817WKFWY@szxga02-in.huawei.com> for sip@ietf.org; Wed, 27 Jun 2007 10:36:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK900BTTWKEOG@szxga02-in.huawei.com> for sip@ietf.org; Wed, 27 Jun 2007 10:36:15 +0800 (CST) Received: from w39649a ([10.85.29.26]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK900737WK9Q3@szxml04-in.huawei.com> for sip@ietf.org; Wed, 27 Jun 2007 10:36:14 +0800 (CST) Date: Wed, 27 Jun 2007 10:36:09 +0800 From: Xiao Wang Subject: RE: [Sip] Could a UA issue a new NOTIFY before thepreviousNOTIFYtransaction has completed? In-reply-to: To: 'Gerald Yan' , 'Bruce Qi' , 'SIP' , 'Paul Kyzivat' Message-id: <03bb01c7b863$eb8dcb80$1a1d550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Ace0aXtf731A11W6T5CafYAj9Xe5hwD8EiRQAAIdxnA= X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: 'Peili Xu' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The Partial Notification mechanism requires PA issue NOTIFY in regular sequence. " The PA MUST NOT send a new NOTIFY request that contains a partial notification for the same Request-URI until it has received a final response from the watcher for the previous one or the previous NOTIFY request has timed out. " Xiao > -----Original Message----- > From: Gerald Yan [mailto:gerald.yan@utstar.com] > Sent: Wednesday, June 27, 2007 9:32 AM > To: Bruce Qi; SIP; Paul Kyzivat > Cc: Peili Xu > Subject: =B4=F0=B8=B4: [Sip] Could a UA issue a new NOTIFY before > thepreviousNOTIFYtransaction has completed? >=20 > This issue may occur in the case of issuing NOTIFY to multiple = SUBSCRIBE or > REFER in a dialog. >=20 > Best regards > Gerald > Tel:86-755-26952899 34617 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Bruce Qi [mailto:qibj@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2007-06-22 9:05 > =CA=D5=BC=FE=C8=CB: SIP; Paul Kyzivat > =B3=AD=CB=CD: Peili Xu > =D6=F7=CC=E2: Re: [Sip] Could a UA issue a new NOTIFY before > thepreviousNOTIFYtransaction has completed? >=20 > Hi Paul: > Is This issue belong to the internal implementation of SIP production? > Beacuse I think there are many similar issues in the development of = SIP > production. >=20 > Thanks and Regards > Burce Qi >=20 >=20 > ----- Original Message ----- > From: "Paul Kyzivat" > To: "Arunachalam Venkatraman (arunvenk)" > Cc: ; "yan" > Sent: Friday, June 22, 2007 7:48 AM > Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous NOTIFY > transaction has completed? >=20 >=20 > > > > > > Arunachalam Venkatraman (arunvenk) wrote: > >> However, if you are using UDP and if the data in the second NOTIFY = is > >> additive to and not replacing the prior NOTIFY, you may run into = the > >> issue of out-of-sequence delivery. > > > > This can be a problem even when using TCP if there are proxies in = the > > path. There is no requirement for proxies to deliver messages in the > > order they receive them. > > > > Paul > > > >> > = ------------------------------------------------------------------------ > >> > >> *From:* Robert Sparks [mailto:rjsparks@nostrum.com] > >> *Sent:* Wednesday, June 20, 2007 12:18 PM > >> *To:* yan > >> *Cc:* sip@ietf.org > >> *Subject:* Re: [Sip] Could a UA issue a new NOTIFY before the = previous > >> NOTIFYtransaction has completed? > >> > >> > >> > >> Generally speaking, yes. > >> > >> > >> > >> An individual event package may restrict that behavior though. > >> > >> > >> > >> RjS > >> > >> > >> > >> On Jun 15, 2007, at 12:16 PM, yan wrote: > >> > >> > >> > >> hi: > >> > >> Could anyone answer me the question: > >> > >> Can a UA issue a new NOTIFY before the previous NOTIFY transaction = has > >> completed? > >> > >> thx > >> > >> > >> > >> yan > >> > >> > >> > >> > = ------------------------------------------------------------------------ > >> > >> 150 =CD=F2 =C8=CB =CD=AC =CA=B1 =D4=DA =CD=E6 =B5=C4 =CD=F8 = =D3=CE=A3=AC=C4=E3 =B2=BB =CA=D4 =CA=D4 =C2=F0 =A3=BF > >> > >> > >> _______________________________________________ > >> > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> > >> This list is for NEW development of the core SIP Protocol > >> > >> Use sip-implementors@cs.columbia.edu > >> for questions on current = sip > >> > >> Use sipping@ietf.org for new developments = on > >> the application of sip > >> > >> > >> > >> > >> > = ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Jun 26 23:29:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ODA-00015N-OG; Tue, 26 Jun 2007 23:28:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3OD7-00015G-4U for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 23:28:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3OD6-000157-Qq for sip@ietf.org; Tue, 26 Jun 2007 23:28:52 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3OD2-0001zJ-Io for sip@ietf.org; Tue, 26 Jun 2007 23:28:52 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I3OCw-0004iQ-3y; Tue, 26 Jun 2007 22:28:42 -0500 Message-ID: <4681DA3C.8090607@softarmor.com> Date: Tue, 26 Jun 2007 22:32:12 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> In-Reply-To: <46819819.5080107@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > Well, I'm going to be contrarian here. I'm not convinced that this is > needed. > > I think certificate based authentication is a great idea. However, I am > not sure I understand why TLS is not an appropriate solution. > I think it is very simple why TLS is not appropriate. TLS doesn't work across proxies, and would therefore require the edge proxy to do authentication. This is why we conventionally use digest or basic auth over TLS. Certificate authentication would provide the flexibility of TLS + basic (no challenge/response) with security better than TLS+digest (no replay). Of course, SIPSEC is another alternative. -- 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 sip-bounces@ietf.org Tue Jun 26 23:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3OGw-00044M-AR; Tue, 26 Jun 2007 23:32:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3OGu-0003yv-Um for sip-confirm+ok@megatron.ietf.org; Tue, 26 Jun 2007 23:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3OGu-0003wo-KU for sip@ietf.org; Tue, 26 Jun 2007 23:32:48 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3OGp-0002tG-VQ for sip@ietf.org; Tue, 26 Jun 2007 23:32:48 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I3OGo-0004j3-5i; Tue, 26 Jun 2007 22:32:42 -0500 Message-ID: <4681DB2C.2090306@softarmor.com> Date: Tue, 26 Jun 2007 22:36:12 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <46819A15.9030704@cisco.com> In-Reply-To: <46819A15.9030704@cisco.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Jonathan Rosenberg wrote: > If you are worried about cases of local proxies in untrusted networks, > separate from your home proxy - well there are tons of problems in that > model and its something we need to discourage. I think we're worried about having two authentication domains -- the one operated by your home proxy (and possibly any "tweeners" like the edge proxy), and the one operated by a 3rd party from who you acquire services but that does not necessarily have a business relationship with and transitive trust of your home proxy. Today, the 3rd party would do digest auth (or with SIPS, maybe basic), but that has its own set of issues. -- 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 sip-bounces@ietf.org Wed Jun 27 03:03:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3RYD-0005KC-7c; Wed, 27 Jun 2007 03:02:53 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3RY9-0005Iz-08 for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 03:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3RY4-0005Gj-O6 for sip@ietf.org; Wed, 27 Jun 2007 03:02:44 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3RVd-0004fL-A0 for sip@ietf.org; Wed, 27 Jun 2007 03:00:17 -0400 Received: (qmail 27520 invoked by uid 0); 27 Jun 2007 07:00:11 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 27 Jun 2007 07:00:11 -0000 Message-ID: <003101c7b888$76b05880$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Wed, 27 Jun 2007 08:57:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Sip] RFC3261 issue: no integrity protection for ACK X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org RFC3261 section 22.1 states: Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. This means that integrity cannot be verified for the original request URI or any body (e.g. in case of offerless INVITE scenario) for ACKs. It also means that proxies and UAS need to maintain state in order to authenticate ACKs. Even though ACK cannot be challenged, it would still be possible for the UAC to calculate a digest as usual, using the same username/password as INVITE and the same nonce. Is this an omission, is there any reason why this is done the way it is? Regards, Jeroen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 27 03:08:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Rds-0006fp-2u; Wed, 27 Jun 2007 03:08:44 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3Rdp-0006fg-ST for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 03:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Rdp-0006fY-I1 for sip@ietf.org; Wed, 27 Jun 2007 03:08:41 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Rdj-0005vJ-Rv for sip@ietf.org; Wed, 27 Jun 2007 03:08:41 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5R785Hb014491; Wed, 27 Jun 2007 10:08:30 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:08:28 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:08:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Keepalive mechanisms for TCP flows in outbound-08 Date: Wed, 27 Jun 2007 10:08:27 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03DAAE41@esebe103.NOE.Nokia.com> In-Reply-To: <953beacc0706211056j5b65c646t43088922152b59f2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Keepalive mechanisms for TCP flows in outbound-08 Thread-Index: Ace0LXeFVQCB71fESrW7IetAJ0gL9wEVTxCg References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> <953beacc0706211056j5b65c646t43088922152b59f2@mail.gmail.com> From: To: X-OriginalArrivalTime: 27 Jun 2007 07:08:28.0648 (UTC) FILETIME=[F65A1E80:01C7B889] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi Rohan, To start with I have to apologize that I have not been able to attend the latest IETF meetings (and will not be able to make it for the next meeting either). That said I try to be reasonable in my posts to the mailing lists even if I am not totally happy to the fact that these issues were raised already in March but will not be addressed before the end of June. Last year Outbound was considered urgent and many WG members wanted it to be finished as soon as possible, but recently the push to get it out seems to have vanished somewhere. Maybe there has been something more urgent gaining the focus. Responding to the comments you made: >At IETF68 we agreed to add an indicator "timed-keepalive" that the >*server* expects keepalives to happen according to the timers >recommended in the draft. If the server asks for this, then the >client needs to send pings (STUN over UDP or double CRLF over TCP or >TLS). =20 I was able to find a note in the IETF68 SIP meeting minutes for this, however I am not able to grasp the value of this indicator (unless it is supposed to carry a value for the timers, but how could the server know the keepalive times of the NATs between the UA and proxy ?) >The *client* can tell if the server will send pongs (STUN >binding responses over UDP, or single CRLF over TCP or TLS) if the >server advertises "keep-stun" or "keep-crlf". This allows a battery >operated client to use TCP keepalives or send pings less often if the >server allows, and it allows the client in general to know if they >should expect to receive pongs. What I am worried about all this is that it seems to make the=20 machinery quite complex. My preference would be to keep things simple as creeping complexity seems to be a common problem for SIP and its extensions. (E.g. I have heard many concerns that the specs from the SIMPLE WG are really far from simple :-) Yes I was one of the proponents for the UA probing STUN support of proxy before starting to send STUN requests to the SIP port of the proxy. However one solution for that, OPTIONS probing for STUN support, was ultimately deemed too complex in IETF68 and was agreed to be removed from the draft according to the minutes. To me it seems that introduction of various flags like "timed-keepalive", "keep-stun" and "keep-crlf" will in the end have similar effect to the complexity, which is not probably justified by the value gained. I even fail to see how those flags would really help any battery operated mobile device. The only thing which really helps is the possibility for the UA to use TCP instead of UDP as TCP has longer keepalive timers. After this email from Cullen in the end of March... http://www1.ietf.org/mail-archive/web/sip/current/msg18514.html=20 ... I was expecting to see a bit different solution in the next version of the Outbound draft as suggested by me and=20 Christer (to what Cullen agreed): 1. UA would check the transports supported by the proxy via DNS (NAPTR and/or SRV) 2. The proxy would indicate its Outbound support e.g. by adding 'ob' parameter to its URI within the Path header 3. When UA knows the supported transports (from DNS) and Outbound support (from Path header) it can be sure that the proxy supports all keepalive methods Outbound has specified for those transports. At this point the UA can choose its keepalive method amongst: a) UDP: UA MUST use STUN b) TCP: UA can use either CRLF or TCP keepalives 4. Whatever keepalive method (type of pings) is selected by the UA, the proxy will send corresponding responses (pongs): a) UDP: STUN responses b) TCP: CRLF pongs or TCP ACKs 5. When sending the keepalives the UA would use timers as specified in the normative text of SIP Outbound draft. Defined like that all the other flags "timed-keepalive", "keep-stun" and "keep-crlf" could be removed from the draft. I do not see enough value for those flags which seem to=20 a) enable the proxy to support just one keepalive method=20 for TCP; and b) somehow complex negotiation between UA and proxy whether=20 regular keepalive or heartbeat messages are expected. Any comments to this proposal ? If you find it acceptable, could you please incorporate it either within the next version of the Outbound draft or raise it as an open question for the meeting to decide ? P.S. Earlier I gave a comment like this for CRLF "pongs": >> How does the addition of CRLF keepalive without CRLF "pong" >> make the situation worse compared using TCP keepalive, which >> has been considered acceptable for Outbound over several >> successive draft revisions and is still there without any >> "pong" other than TCP ACK ? One of my colleagues pointed out that the OS implementations for TCP keepalive typically have some timer for receiving the ACKs. Thus it would mean TCP keepalive has an implicit timeout behaviour which CRLF keepalives lack. After this comment I can accept the value of CRLF "pong" and do not have any problem with it. Thanks, Erkki >On 3/8/07, Erkki.Koivusalo@nokia.com wrote: >> Hi, >> >> >> Question 1: >> >> >> >> Is the single CRLF "pong" necessary or could the UA detect the >> >> flow failure just by receiving a socket or ICMP error when the >> >> connection is broken and not able to pass the double-CRLF "ping" >> >> to the proxy ? >> > >> >Sure, if you don't mind not getting calls for 10 minutes.=20 >And if some >> >moron hasn't blocked ICMP on your network (which unfortunately >> >corpsec guidelines frequently recommend). >> >> To overcome this problem, doesn't Outbound strongly promote the >> UA registering over multiple flows ? >> >> This requires the UA to detect when a flow fails. Since >> such detection takes time and leaves a window of opportunity for >> missed incoming requests, this mechanism allows the UA to use >> multiple flows to the proxy or registrar. >> >> Are you suggesting that this mechanism in the Outbound only >> has limited or even no value ? >> >> >It can take TCP a LONG time to know a flow has failed. This is a >> >large part of why I liked the STUN model. >> >> How does the addition of CRLF keepalive without CRLF "pong" >> make the situation worse compared using TCP keepalive, which >> has been considered acceptable for Outbound over several >> successive draft revisions and is still there without any >> "pong" other than TCP ACK ? >> >> And as you say, it can take TCP a LONG time to know a flow=20 >has failed, >> but not necessarily. The device which rebooted might indicate the >> broken connection by sending TCP RST, which immediately tells the >> sender about the flow failure. >> >> Even the STUN over TCP model will not guarantee an immediate >> detection of a failed flow as Outbound suggests that the time >> between successive keepalives over TCP should be between 95 and >> 120 seconds on top of which the STUN transaction adds 8 seconds >> to wait for the response. So even with STUN or CRLF "ping-pong" >> you could not getting calls for two minutes if the UA is relying >> on one single flow only or using two flows towards two different >> proxies over a single NAT which reboots. >> >> >> I am still questioning whether the requirement to add CRLF "pong" >> and 'keep-crlf' URI tags are really worth the extra complexity. >> Personally I am not at all convinced about it. >> >> Regards, >> >> Erkki >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 27 06:03:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UMk-0007pb-8E; Wed, 27 Jun 2007 06:03:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3UMi-0007ms-VF for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 06:03:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UMi-0007mj-L5 for sip@ietf.org; Wed, 27 Jun 2007 06:03:12 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3UMW-0004hx-BL for sip@ietf.org; Wed, 27 Jun 2007 06:03:12 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l5RA2xuR005575 for ; Wed, 27 Jun 2007 12:02:59 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l5RA2s2q029740 for ; Wed, 27 Jun 2007 12:02:59 +0200 Received: from MCHP7IDA.ww002.siemens.net ([139.25.131.144]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 12:02:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2007 12:02:48 +0200 Message-ID: <0D22E3C1A7D7A843B12BF8C6F0A40758021EC8AB@MCHP7IDA.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP SAML Draft Review by Sebastian Felis Thread-Index: AcezRtF8/UtxCwG9TXaSfFQXnBrmrQFW1dqg From: "Tschofenig, Hannes" To: "SIP IETF" X-OriginalArrivalTime: 27 Jun 2007 10:02:55.0426 (UTC) FILETIME=[5509B220:01C7B8A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Sip] SIP SAML Draft Review by Sebastian Felis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org FYI -----Urspr=FCngliche Nachricht----- Von: ext Sebastian Felis [mailto:felis@netlab.nec.de]=20 Gesendet: Mittwoch, 20. Juni 2007 16:25 An: Tschofenig, Hannes Cc: Martin Stiemerling; Daniele Abbadessa Betreff: Re: SIP SAML Draft Review Hi Hannes, I have reviewed the SIP SAML draft version 2. Unfortunately I am not very familiar with SAML but SIP. But anyway, I hope I can give some input for this draft. Further more, sorry for being late. First of all: Editorial comments Page 4: Add the acronym AS to Authentication Server as for UAS and AUC Pate 11: Remove double space in the headline of 6.1. and 6.1.3.2. Other two comments: - In my point of view, the draft focuses only on trait-based authorization and tries to deploy trait-based authorization using SAML. It does not try to specify SAML over SIP, which I was expected. Therefore, it is more on an SAML artifact resolution protocol using SIP. The term "artifact resolution protocol" is never mentioned in your = draft. And how is the integration of SAML over SIP which carries the assertion in the SIP message, eg. using MIME multiparts. But I guess, this is now concerned by the new issue 10 in http://www.tschofenig.priv.at:8080/saml-sip/issue10. - Another topic is the usage of the term "Authentication Server" which has the acronym AS. Since the term is originating from the trait-based authorization draft, this term should be fine. But from the IMS perspective, the acronym AS is "Application Server". By today, the SIP (p)rotocol is more and more associated with IMS and touches the terms of IMS. Further, the term Authentication Server is not a common term in SAML. So I propose to use another term, which is more SIP/IMS and/or SAML conform, e.g. Identity Provider in case of SAML. BR Sebastian Felis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 27 11:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ZKk-0002rg-5X; Wed, 27 Jun 2007 11:21:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3ZKh-0002rO-0Y for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 11:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ZKg-0002rG-N8 for sip@ietf.org; Wed, 27 Jun 2007 11:21:26 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ZKW-0006jJ-Vz for sip@ietf.org; Wed, 27 Jun 2007 11:21:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Jun 2007 11:20:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAA8cgkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,467,1175486400"; d="scan'208"; a="124682458:sNHT58726404222" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5RFKt8o002337; Wed, 27 Jun 2007 11:20:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5RFKOM3011190; Wed, 27 Jun 2007 15:20:55 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 11:20:43 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 11:20:42 -0400 Message-ID: <46828046.9010104@cisco.com> Date: Wed, 27 Jun 2007 11:20:38 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Xiao Wang Subject: Re: [Sip] Could a UA issue a new NOTIFY before thepreviousNOTIFYtransaction has completed? References: <03bb01c7b863$eb8dcb80$1a1d550a@china.huawei.com> In-Reply-To: <03bb01c7b863$eb8dcb80$1a1d550a@china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Jun 2007 15:20:42.0777 (UTC) FILETIME=[BA109090:01C7B8CE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4954; t=1182957655; x=1183821655; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Could=20a=20UA=20issue=20a=20new=20NOTIFY=20b efore=20thepreviousNOTIFYtransaction=0A=20has=20completed? |Sender:=20 |To:=20Xiao=20Wang=20; bh=zMDJpAbOSYRaoP3f7dJ7cbntKhC+E/nUv6Mt2hMUotU=; b=Fd/aZOoGfXUy0ID9T81cbMzctWCL+kcNjd/iYGE5/m8A5bOUY1eupEkNlYE5lYJ/joIJgGHh cUgJemJY4Ls8bixcQ7iW3v8QlXaczK6v1FmCQL0NwRlIE1WkZB2ZdboL; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: 'SIP' , 'Peili Xu' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org What you say is true, but applies specifically to partial notifications. Since they send deltas from the previous one they won't work if processed out of order. Some event packages also need such restrictions. But it isn't a general restriction. Paul Xiao Wang wrote: > The Partial Notification mechanism requires PA issue NOTIFY in regular > sequence. > > " The PA MUST NOT send a new NOTIFY request that contains a partial > notification for the same Request-URI until it has received a final > response from the watcher for the previous one or the previous NOTIFY > request has timed out. " > > Xiao >> -----Original Message----- >> From: Gerald Yan [mailto:gerald.yan@utstar.com] >> Sent: Wednesday, June 27, 2007 9:32 AM >> To: Bruce Qi; SIP; Paul Kyzivat >> Cc: Peili Xu >> Subject: ´ð¸´: [Sip] Could a UA issue a new NOTIFY before >> thepreviousNOTIFYtransaction has completed? >> >> This issue may occur in the case of issuing NOTIFY to multiple SUBSCRIBE > or >> REFER in a dialog. >> >> Best regards >> Gerald >> Tel:86-755-26952899 34617 >> >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: Bruce Qi [mailto:qibj@huawei.com] >> ·¢ËÍʱ¼ä: 2007-06-22 9:05 >> ÊÕ¼þÈË: SIP; Paul Kyzivat >> ³­ËÍ: Peili Xu >> Ö÷Ìâ: Re: [Sip] Could a UA issue a new NOTIFY before >> thepreviousNOTIFYtransaction has completed? >> >> Hi Paul: >> Is This issue belong to the internal implementation of SIP > production? >> Beacuse I think there are many similar issues in the development of SIP >> production. >> >> Thanks and Regards >> Burce Qi >> >> >> ----- Original Message ----- >> From: "Paul Kyzivat" >> To: "Arunachalam Venkatraman (arunvenk)" >> Cc: ; "yan" >> Sent: Friday, June 22, 2007 7:48 AM >> Subject: Re: [Sip] Could a UA issue a new NOTIFY before the previous > NOTIFY >> transaction has completed? >> >> >>> >>> Arunachalam Venkatraman (arunvenk) wrote: >>>> However, if you are using UDP and if the data in the second NOTIFY is >>>> additive to and not replacing the prior NOTIFY, you may run into the >>>> issue of out-of-sequence delivery. >>> This can be a problem even when using TCP if there are proxies in the >>> path. There is no requirement for proxies to deliver messages in the >>> order they receive them. >>> >>> Paul >>> >> ------------------------------------------------------------------------ >>>> *From:* Robert Sparks [mailto:rjsparks@nostrum.com] >>>> *Sent:* Wednesday, June 20, 2007 12:18 PM >>>> *To:* yan >>>> *Cc:* sip@ietf.org >>>> *Subject:* Re: [Sip] Could a UA issue a new NOTIFY before the previous >>>> NOTIFYtransaction has completed? >>>> >>>> >>>> >>>> Generally speaking, yes. >>>> >>>> >>>> >>>> An individual event package may restrict that behavior though. >>>> >>>> >>>> >>>> RjS >>>> >>>> >>>> >>>> On Jun 15, 2007, at 12:16 PM, yan wrote: >>>> >>>> >>>> >>>> hi: >>>> >>>> Could anyone answer me the question: >>>> >>>> Can a UA issue a new NOTIFY before the previous NOTIFY transaction has >>>> completed? >>>> >>>> thx >>>> >>>> >>>> >>>> yan >>>> >>>> >>>> >>>> >> ------------------------------------------------------------------------ >>>> 150 Íò ÈË Í¬ ʱ ÔÚ Íæ µÄ Íø ÓΣ¬Äã ²» ÊÔ ÊÔ Â𠣿 >>>> >>>> >>>> _______________________________________________ >>>> >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> >>>> This list is for NEW development of the core SIP Protocol >>>> >>>> Use sip-implementors@cs.columbia.edu >>>> for questions on current sip >>>> >>>> Use sipping@ietf.org for new developments on >>>> the application of sip >>>> >>>> >>>> >>>> >>>> >> ------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>> This list is for NEW development of the core SIP Protocol >>>> Use sip-implementors@cs.columbia.edu for questions on current sip >>>> Use sipping@ietf.org for new developments on the application of sip >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 27 15:50:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dX9-0005XL-2e; Wed, 27 Jun 2007 15:50:35 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3dX7-0005TY-Fp for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dX7-0005RB-4O; Wed, 27 Jun 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3dX6-0008S4-UH; Wed, 27 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9C776175D0; Wed, 27 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3dWc-0001E2-74; Wed, 27 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 27 Jun 2007 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-sips-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@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 use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) Author(s) : F. Audet Filename : draft-ietf-sip-sips-05.txt Pages : 56 Date : 2007-6-27 This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sips-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-sips-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: <2007-6-27140252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sips-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sips-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-27140252.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Wed Jun 27 15:51:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dXb-0006tb-CJ; Wed, 27 Jun 2007 15:51:03 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3dXR-0006bl-E6 for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 15:50:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3dXR-0006bY-2T; Wed, 27 Jun 2007 15:50:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3dXQ-0008Uo-R6; Wed, 27 Jun 2007 15:50:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id A7E2A2AC7F; Wed, 27 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I3dWc-0001E8-8n; Wed, 27 Jun 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 27 Jun 2007 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-outbound-09.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@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 : Managing Client Initiated Connections in the Session Initiation Protocol (SIP) Author(s) : C. Jennings, R. Mahy Filename : draft-ietf-sip-outbound-09.txt Pages : 42 Date : 2007-6-27 The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs), prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-outbound-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-outbound-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: <2007-6-27140959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-outbound-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-outbound-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-27140959.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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-- From sip-bounces@ietf.org Wed Jun 27 16:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eJ9-0004Kd-5S; Wed, 27 Jun 2007 16:40:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3eJ6-00041x-Ny for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 16:40:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eJ6-0003tW-4c for sip@ietf.org; Wed, 27 Jun 2007 16:40:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3eJ5-0005RG-Sk for sip@ietf.org; Wed, 27 Jun 2007 16:40:08 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id C63D32AC65; Wed, 27 Jun 2007 20:39:32 +0000 (GMT) Received: from stntexch11.cis.neustar.com ([10.31.13.50]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 16:39:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Wed, 27 Jun 2007 16:39:32 -0400 Message-ID: <9D18525F6EF33947BDEF23374EF26C7A06CD97@stntexch11.cis.neustar.com> In-Reply-To: <46819819.5080107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlg From: "Peterson, Jon" To: "Jonathan Rosenberg" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 27 Jun 2007 20:39:32.0631 (UTC) FILETIME=[4458A270:01C7B8FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I also have to admit I'm a skeptical. Various forms of non-hop-by-hop = authentication with certificates were enabled by S/MIME, especially in = conjunction with entities like AIBs. As far as I'm concerned, the = mechanics have had their day in court, and it didn't go well. We can = grapple with the syntax to try to find something slightly different that = will actually appeal to the implementation community, but I don't think = the problem was that we had the wrong syntax. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, June 26, 2007 3:50 PM > To: DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: Re: [Sip] Certificate authentication in SIP >=20 >=20 > Well, I'm going to be contrarian here. I'm not convinced that this is=20 > needed. >=20 > I think certificate based authentication is a great idea.=20 > However, I am=20 > not sure I understand why TLS is not an appropriate solution. >=20 > DRAGE, Keith (Keith) wrote: >=20 > > (As WG chair) > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > te-auth-03 > > .txt=20 > >=20 > > Describes a set of requirements for: > >=20 > > This document defines requirements for adding certificate > > authentication to the Session Initiation Protocol (SIP). This > > document is being presented with the intention of providing clear > > requirements to any potential solutions specifying certificate > > authentication within SIP networks. Supporting certificate > > authentication in SIP would provide strong authentication and > > increase the types of possible deployment scenarios. > >=20 > > (Before we go any further, please forget all about the solutions > > document - that comes later and we are not dealing with it now) > >=20 > > We need to decide whether there is support for a body of=20 > work in this > > area, and therefore whether we should charter some=20 > requirements work in > > the SIP WG. > >=20 > > (Because this is security related we have agreed that SIP does the > > requirements drafting and not SIPPING) > >=20 > > So can I hear opinions of the WG on: > >=20 > > - whether this represents a problem space that the working group > > should draft requirements on? > >=20 > > - whether the problem space exists but is something slightly > > different, and if so what is that problem space? > >=20 > > - whether there is a more general problem that the security area > > should be addressing, rather than the SIP group addressing something > > specific? > >=20 > > - based on your answers to the first three questions, whether this > > draft is essentially in the right direction to be adopted as the WG > > draft assuming we create the charter item, or whether we=20 > need to seek > > some other input draft? > >=20 > > - and finally, whether (assuming we go ahead with this work) there > > is any work in any other IETF WG that we should take account of? > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Jun 27 16:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eN8-0000nN-NQ; Wed, 27 Jun 2007 16:44:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3eN7-0000n5-HT for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 16:44:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eN7-0000ms-7N for sip@ietf.org; Wed, 27 Jun 2007 16:44:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3eMf-0000YY-Vo for sip@ietf.org; Wed, 27 Jun 2007 16:44:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2007 13:43:49 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAL9ogkarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,467,1175497200"; d="scan'208"; a="5725280:sNHT13271796" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5RKhnuI015215; Wed, 27 Jun 2007 13:43:49 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5RKhPnC028653; Wed, 27 Jun 2007 20:43:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 13:43:30 -0700 Received: from [128.107.109.154] ([128.107.109.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 13:43:30 -0700 Message-ID: <4682CBF1.9000401@cisco.com> Date: Wed, 27 Jun 2007 16:43:29 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> In-Reply-To: <4681DA3C.8090607@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2007 20:43:30.0173 (UTC) FILETIME=[D1EEAAD0:01C7B8FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1127; t=1182977029; x=1183841029; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=IjRL0zz7I2+h+JtlMhEZqQ7b70MgwQUADmprqBUfi8s=; b=rrBKKMVKZnZmFTA/WyV+BVCD3ki9kif2KF1MVw8T+H0Ym0tu+oF+TTm6BZYGFCoIHNxGv0HX At1HbvAsi8HT9U1QktF2/UnHAnEF5VcSuZk27lwbIxwDEbFvY/LdRmZC; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > Jonathan Rosenberg wrote: > >>Well, I'm going to be contrarian here. I'm not convinced that this is >>needed. >> >>I think certificate based authentication is a great idea. However, I am >>not sure I understand why TLS is not an appropriate solution. >> > > > I think it is very simple why TLS is not appropriate. TLS doesn't work > across proxies, and would therefore require the edge proxy to do > authentication. So what? I think thats what ought to happen. I'd like to see some specific use cases where this can't work with the edge proxy performing the authentication. Keep in mind, we are talking about *certificate* authentication; that doesn't (by definition) required any kind of pre-arranged secret - only a common root CA. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.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 sip-bounces@ietf.org Wed Jun 27 22:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3jqx-0008MQ-1D; Wed, 27 Jun 2007 22:35:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3jqv-0008ML-Le for sip-confirm+ok@megatron.ietf.org; Wed, 27 Jun 2007 22:35:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3jqv-0008MD-Bk for sip@ietf.org; Wed, 27 Jun 2007 22:35:25 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3jqq-0005M4-UW for sip@ietf.org; Wed, 27 Jun 2007 22:35:25 -0400 Received: from [192.168.2.99] (adsl-67-112-220-125.dsl.sntc01.pacbell.net [67.112.220.125]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l5S2ZFZd045000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Jun 2007 21:35:20 -0500 (CDT) (envelope-from rjsparks@estacado.net) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: SIP IETF From: Robert Sparks Date: Wed, 27 Jun 2007 19:35:14 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Sip] Changes to the INVITE transaction to address bug 769 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Everyone - I've put together a proposal for addressing the spec bug captured at http://bugs.sipit.net/show_bug.cgi?id=769 Please read through http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt and comment. 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 sip-bounces@ietf.org Thu Jun 28 04:34:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pRu-0008MO-Qk; Thu, 28 Jun 2007 04:33:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3pRt-0008MD-2p for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 04:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3pRs-0008M5-AV for sip@ietf.org; Thu, 28 Jun 2007 04:33:56 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3pR4-0002Yy-LN for sip@ietf.org; Thu, 28 Jun 2007 04:33:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5S8WoIt007014; Thu, 28 Jun 2007 11:33:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 11:32:54 +0300 Received: from esebe103.NOE.Nokia.com ([172.21.138.219]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 11:32:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Sip] Keepalive mechanisms and related flags in outbound-09 Date: Thu, 28 Jun 2007 11:32:53 +0300 Message-ID: <8B1D53AEF7B03449A6D3771B3B7F850F03DAB59D@esebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Keepalive mechanisms and related flags in outbound-09 Thread-Index: Ace0LXeFVQCB71fESrW7IetAJ0gL9wEVTxCgADS0F+A= References: <8B1D53AEF7B03449A6D3771B3B7F850F036F845C@esebe103.NOE.Nokia.com> <8B1D53AEF7B03449A6D3771B3B7F850F036F8BC2@esebe103.NOE.Nokia.com> <953beacc0706211056j5b65c646t43088922152b59f2@mail.gmail.com> From: To: X-OriginalArrivalTime: 28 Jun 2007 08:32:53.0993 (UTC) FILETIME=[EBF22D90:01C7B95E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: sip@ietf.org, fluffy@cisco.com, dean.willis@softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org =20 Hi, I have today had a look into the fresh Outbound-09 to see how it addresses the keepalive issues in comparison to the proposal I submitted originally in the beginning of March and resent it yesterday. My first questions are related to this statement: Clients MUST support this CRLF keepalive. If so, what is the value of promoting the TCP Keepalive within SIP Outbound ? In which circumstancies an UA supporting TCP=20 Keepalive would instead select sending CRLF keepalive ? Further on, I like this piece of text within Outbound-09: The client needs to perform normal RFC 3263 [4] SIP DNS resolution on the URI from the outbound-proxy-set to pick a transport. Once a transport is selected, the UA selects a keepalive approach that is allowed for that transport ...=20 That approach is elegant and consistent with RFC 3263. But I still dislike these pieces of text: ... and that is allowed by the server based on the tags in the URI=20 from the outbound-proxy-set. User Agents that form flows check if the configured URI they are connecting to has a 'keep-crlf' URI parameter (defined in Section 12). If the parameter is present and the UA is not already performing keepalives using another supported mechanism, the UA can send keep alives as described in this section. User Agents that form flows, check if the configured URI they are connecting to has a 'keep-stun' URI parameter (defined in Section 12). If the parameter is present and the UA is not already performing keepalives using another supported mechanism, the UA can periodically perform keepalive checks by sending STUN [3] Binding Requests over the flow as described in Section 8.=20 Outbound-09 suggests that configured proxy URIs could contain 'keep-crlf' or 'keep-stun' parameters, with which the UAs could check whether the proxy supports the corresponding keepalive mechanism before starting to send such keepalives. Instead of=20 all that I simply suggest using the 'ob' parameter for the proxy=20 URI to indicate that the proxy supports SIP Outbound and all the=20 keepalive mechanisms defined in SIP Outbound for those transports=20 the proxy supports according to DNS. Rationale: 1. SIP Outbound anyway already mandates compliant proxies to support all keepalive mechanisms (see section 5.4) so there is no need to define separate flags for each of those mechanisms. One single flag for Outbound support is sufficient indication. 2. The draft has already defined the 'ob' URI parameter and how the proxy should use it. My proposal is to use the flag as defined but additionally to bundle the semantics of separate keepalive flags to this single 'ob' parameter. 3. The UA could check the presence of 'ob' parameter within the proxy URI either a) within its configured outbound-proxy-set; or b) Path header received within 200 OK to REGISTER (like suggested in section 8) 4. Simple is better: less flags to be introduced to IANA, to the URIs or to the implementations. Resulting URIs would also be shorter with this single and short parameter. Finally I do not find any value for the 'timed-keepalives'=20 parameter. It was agreed in IETF68 but I was not attending the meeting and I have not seen the rationale for it anywhere. For the proxy point of view what is the difference whether or not the proxy URI contains this parameter ? If the parameter is within the URI, the proxy can be sure that it receives the keepalives with intervals defined in the spec but otherwise the UA could select longer intervals. However the spec does not specify any actions for the proxy to check how often it receives the keepalive messages so what is the point to have such a URI parameter ? Instead of that I would suggest dropping this parameter and either: a) mandate the UA always to use timers as defined in the draft or b) let the UA always to choose any timer values it wants to use=20 and make the timer values in the draft as recommendations Option b) could be better if the UA later on has some=20 mechanism (like STUN extension etc.) to ask the middleboxes to adjust their timer behaviour. Example of URIs for a proxy supporting all keepalive methods: Outbound-09: =20 sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob My proposal: =20 sip:pri.example.com;lr;ob Just guess why I prefer the latter ;-) Any comments ? Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 28 08:57:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tYP-0001CM-B9; Thu, 28 Jun 2007 08:56:57 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3tYN-00018e-LM for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 08:56:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tYN-00016M-Aj for sip@ietf.org; Thu, 28 Jun 2007 08:56:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3tYH-0004UY-EX for sip@ietf.org; Thu, 28 Jun 2007 08:56:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 28 Jun 2007 08:56:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHVMg0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,470,1175486400"; d="scan'208"; a="63887572:sNHT30891156" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5SCunGR026939; Thu, 28 Jun 2007 08:56:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SCuiZF017511; Thu, 28 Jun 2007 12:56:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 08:56:44 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 08:56:44 -0400 Message-ID: <4683B00B.3060700@cisco.com> Date: Thu, 28 Jun 2007 08:56:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Robert Sparks Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2007 12:56:44.0488 (UTC) FILETIME=[C7A80480:01C7B983] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1313; t=1183035409; x=1183899409; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20Changes=20to=20the=20INVITE=20transaction=20t o=20address=20bug=20769 |Sender:=20 |To:=20Robert=20Sparks=20; bh=qbdX1Je23B4GtAuTsRalbrScUn5mpp8PlVQCYRoC094=; b=HPS/d21LNJic4YehzVSYEArOZ6jZz+jJx7UriXNti4go88djTgAAPZbAqoVBu4wsYRbIFgoc BeqiZ5UDwQjzIqgIBMrmz/cKdjaYDQF3Ej6F9CccJsOGepGp3JhlCEHQ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Robert, I seem to recall from long ago that one reason for forwarding strays was to support restart or failover of a proxy, where internal state of the failed proxy is not preserved. As I recall, the expectation was that while things might not work as well as if the failure had not happened, the situation would be better than if these messages were not forwarded. This is only a vague memory, so it may not be right. But if it is, won't the proposed changes break that? Does it matter? Also, while I see some logic in not forwarding strays for the reasons stated in the draft, if that is a problem that needs to be solved, shouldn't stateless proxies also be banned? Paul Robert Sparks wrote: > Everyone - > > I've put together a proposal for addressing the spec bug captured at > http://bugs.sipit.net/show_bug.cgi?id=769 > > Please read through > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > and comment. > > 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 sip-bounces@ietf.org Thu Jun 28 10:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uyS-0001I2-LG; Thu, 28 Jun 2007 10:27:56 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3uyR-0001DB-7X for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 10:27:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uyQ-0001CZ-Sm for sip@ietf.org; Thu, 28 Jun 2007 10:27:54 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3uyQ-0002Jo-Jl for sip@ietf.org; Thu, 28 Jun 2007 10:27:54 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 28 Jun 2007 07:27:45 -0700 X-IronPort-AV: i="4.16,471,1175497200"; d="scan'208"; a="26921472:sNHT42293340" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:27:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Subject: RE: [Sip] Changes to the INVITE transaction to address bug 769 Date: Thu, 28 Jun 2007 15:27:41 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090B16FC6@EMAILEMEA3.jnpr.net> In-Reply-To: <4683B00B.3060700@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Changes to the INVITE transaction to address bug 769 Thread-Index: Ace5g+jjXhiwnqPfT7ChZuWBi0zkjgAC9FCQ References: <4683B00B.3060700@cisco.com> From: "Gilad Shaham" To: "Paul Kyzivat" , "Robert Sparks" X-OriginalArrivalTime: 28 Jun 2007 14:27:42.0578 (UTC) FILETIME=[7CEE7520:01C7B990] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I guess a stateful proxy would only need stateless forwarding only in the first few minutes of operation (because of timer C) - after that it should have all the transactions. Not sure we can or want to ban stateless proxies though. Isn't this "recovery mode" simply the same as saying that for the first few minutes the stateful proxy acts as both stateful and stateless proxy? > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, June 28, 2007 3:57 PM > To: Robert Sparks > Cc: SIP IETF > Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 >=20 > Robert, >=20 > I seem to recall from long ago that one reason for forwarding strays was > to support restart or failover of a proxy, where internal state of the > failed proxy is not preserved. As I recall, the expectation was that > while things might not work as well as if the failure had not happened, > the situation would be better than if these messages were not forwarded. >=20 > This is only a vague memory, so it may not be right. But if it is, won't > the proposed changes break that? Does it matter? >=20 > Also, while I see some logic in not forwarding strays for the reasons > stated in the draft, if that is a problem that needs to be solved, > shouldn't stateless proxies also be banned? >=20 > Paul >=20 > Robert Sparks wrote: > > Everyone - > > > > I've put together a proposal for addressing the spec bug captured at > > http://bugs.sipit.net/show_bug.cgi?id=3D769 > > > > Please read through > > http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt > > and comment. > > > > 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 > > >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 28 11:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wFF-0006ng-EI; Thu, 28 Jun 2007 11:49:21 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3wFD-0006nF-6R for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 11:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wFC-0006mV-Sj for sip@ietf.org; Thu, 28 Jun 2007 11:49:18 -0400 Received: from web63208.mail.re1.yahoo.com ([69.147.97.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3wEd-0001YO-M7 for sip@ietf.org; Thu, 28 Jun 2007 11:49:18 -0400 Received: (qmail 68716 invoked by uid 60001); 28 Jun 2007 14:48:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=t9DpPi2EqcHxfebZPzZinsxvQ2v+8oZ3nOIl6954AJKqQKprMaC1uzhYFIJlnHWqLX4+Kp3IRC8IK7IWjgaOZ1GAjgN4zTpsbodEXJpU4W7v73JlD0t5jTiRP1Dnngwc8hj+Kcs/CM52e8OKTbGE46zw88n/xElzvp8Izj6R5S0=; X-YMail-OSG: w0zTOQQVM1m0FEIXAu0d7cm7UOiq1IbfCRIIjvM6NRo1avw9zLLIKV8hZK4ofjV1DjiycOM0XDwpM1g8N1Peq3fQDelSvj2f9oblbvd3mLSmgLQmvsl_lkRb8SnT_Ixb Received: from [216.191.234.70] by web63208.mail.re1.yahoo.com via HTTP; Thu, 28 Jun 2007 07:48:42 PDT Date: Thu, 28 Jun 2007 07:48:42 -0700 (PDT) From: Jerry Yin Subject: Re: [Sip] Keepalive mechanisms and related flags in outbound-09 To: Erkki.Koivusalo@nokia.com In-Reply-To: <8B1D53AEF7B03449A6D3771B3B7F850F03DAB59D@esebe103.NOE.Nokia.com> MIME-Version: 1.0 Message-ID: <333369.68561.qm@web63208.mail.re1.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1581726491==" Errors-To: sip-bounces@ietf.org --===============1581726491== Content-Type: multipart/alternative; boundary="0-2087879867-1183042122=:68561" Content-Transfer-Encoding: 8bit --0-2087879867-1183042122=:68561 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Erkki, I think you got a good point. I don't know what is behind the "keep-" parameters. But I don't see a real value using these parameters either. I agree with you with your approach. Here is some more comments. First, if the proxy supports all three kinds of keep alive mechanism, the client is free to choose the one that it supports. Then the keep-parameter is not useful. Second, the client should be able to detect if it's behind a firewall or not (by rport). The client may not send any keep alive packet if it's not behind any firewall. In such case, the configuration with "keep-" parameter would only introduce confusion. Third, if the protocol can solve the problem automatically, it would be better not to introduce any configuration. Right now, there are too many configurations already to deploy on any SIP set. Fourth, similar to the ";transport=udp" parameter which does not need to be configured in any sip set explicitly if the UA can resolve the transport type by using NAPTR/SRV (RFC3263). Therefore again, it's not necessary to configure ";keep-xx" parameter if the proxy supports all of them. Jerry Erkki.Koivusalo@nokia.com wrote: Hi, I have today had a look into the fresh Outbound-09 to see how it addresses the keepalive issues in comparison to the proposal I submitted originally in the beginning of March and resent it yesterday. My first questions are related to this statement: Clients MUST support this CRLF keepalive. If so, what is the value of promoting the TCP Keepalive within SIP Outbound ? In which circumstancies an UA supporting TCP Keepalive would instead select sending CRLF keepalive ? Further on, I like this piece of text within Outbound-09: The client needs to perform normal RFC 3263 [4] SIP DNS resolution on the URI from the outbound-proxy-set to pick a transport. Once a transport is selected, the UA selects a keepalive approach that is allowed for that transport ... That approach is elegant and consistent with RFC 3263. But I still dislike these pieces of text: ... and that is allowed by the server based on the tags in the URI from the outbound-proxy-set. User Agents that form flows check if the configured URI they are connecting to has a 'keep-crlf' URI parameter (defined in Section 12). If the parameter is present and the UA is not already performing keepalives using another supported mechanism, the UA can send keep alives as described in this section. User Agents that form flows, check if the configured URI they are connecting to has a 'keep-stun' URI parameter (defined in Section 12). If the parameter is present and the UA is not already performing keepalives using another supported mechanism, the UA can periodically perform keepalive checks by sending STUN [3] Binding Requests over the flow as described in Section 8. Outbound-09 suggests that configured proxy URIs could contain 'keep-crlf' or 'keep-stun' parameters, with which the UAs could check whether the proxy supports the corresponding keepalive mechanism before starting to send such keepalives. Instead of all that I simply suggest using the 'ob' parameter for the proxy URI to indicate that the proxy supports SIP Outbound and all the keepalive mechanisms defined in SIP Outbound for those transports the proxy supports according to DNS. Rationale: 1. SIP Outbound anyway already mandates compliant proxies to support all keepalive mechanisms (see section 5.4) so there is no need to define separate flags for each of those mechanisms. One single flag for Outbound support is sufficient indication. 2. The draft has already defined the 'ob' URI parameter and how the proxy should use it. My proposal is to use the flag as defined but additionally to bundle the semantics of separate keepalive flags to this single 'ob' parameter. 3. The UA could check the presence of 'ob' parameter within the proxy URI either a) within its configured outbound-proxy-set; or b) Path header received within 200 OK to REGISTER (like suggested in section 8) 4. Simple is better: less flags to be introduced to IANA, to the URIs or to the implementations. Resulting URIs would also be shorter with this single and short parameter. Finally I do not find any value for the 'timed-keepalives' parameter. It was agreed in IETF68 but I was not attending the meeting and I have not seen the rationale for it anywhere. For the proxy point of view what is the difference whether or not the proxy URI contains this parameter ? If the parameter is within the URI, the proxy can be sure that it receives the keepalives with intervals defined in the spec but otherwise the UA could select longer intervals. However the spec does not specify any actions for the proxy to check how often it receives the keepalive messages so what is the point to have such a URI parameter ? Instead of that I would suggest dropping this parameter and either: a) mandate the UA always to use timers as defined in the draft or b) let the UA always to choose any timer values it wants to use and make the timer values in the draft as recommendations Option b) could be better if the UA later on has some mechanism (like STUN extension etc.) to ask the middleboxes to adjust their timer behaviour. Example of URIs for a proxy supporting all keepalive methods: Outbound-09: sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob My proposal: sip:pri.example.com;lr;ob Just guess why I prefer the latter ;-) Any comments ? Regards, Erkki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------------------------- Shape Yahoo! in your own image. Join our Network Research Panel today! --0-2087879867-1183042122=:68561 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi Erkki,
 
I think you got a good point. I don't know what is behind the "keep-" parameters. But I don't see a real value using these parameters either. I agree with you with your approach. Here is some more comments.
 
First, if the proxy supports all three kinds of keep alive mechanism, the client is free to choose the one that it supports. Then the keep-parameter is not useful.
 
Second, the client should be able to detect if it's behind a firewall or not (by rport). The client may not send any keep alive packet if it's not behind any firewall. In such case, the configuration with "keep-" parameter would only introduce confusion.
 
Third, if the protocol can solve the problem automatically, it would be better not to introduce any configuration. Right now, there are too many configurations already to deploy on any SIP set.
 
Fourth, similar to the ";transport=udp" parameter which does not need to be configured in any sip set explicitly if the UA can resolve the transport type by using NAPTR/SRV (RFC3263). Therefore again, it's not necessary to configure ";keep-xx" parameter if the proxy supports all of them.
 
Jerry


Erkki.Koivusalo@nokia.com wrote:

Hi,

I have today had a look into the fresh Outbound-09
to see how it addresses the keepalive issues in comparison
to the proposal I submitted originally in the beginning of
March and resent it yesterday.

My first questions are related to this statement:

Clients MUST support this CRLF keepalive.

If so, what is the value of promoting the TCP Keepalive within
SIP Outbound ? In which circumstancies an UA supporting TCP
Keepalive would instead select sending CRLF keepalive ?


Further on, I like this piece of text within Outbound-09:

The client needs to perform normal RFC 3263 [4] SIP DNS resolution on
the URI from the outbound-proxy-set to pick a transport. Once a
transport is selected, the UA selects a keepalive approach that is
allowed for that transport ...

That approach is elegant and consistent with RFC 3263.

But I still dislike these pieces of text:

... and that is allowed by the server based on the tags in the URI
from the outbound-proxy-set.

User Agents that form flows check if the configured URI they are
connecting to has a 'keep-crlf' URI parameter (defined in
Section 12). If the parameter is present and the UA is not already
performing keepalives using another supported mechanism, the UA can
send keep alives as described in this section.

User Agents that form flows, check if the configured URI they are
connecting to has a 'keep-stun' URI parameter (defined in
Section 12). If the parameter is present and the UA is not already
performing keepalives using another supported mechanism, the UA can
periodically perform keepalive checks by sending STUN [3] Binding
Requests over the flow as described in Section 8.

Outbound-09 suggests that configured proxy URIs could contain
'keep-crlf' or 'keep-stun' parameters, with which the UAs could
check whether the proxy supports the corresponding keepalive
mechanism before starting to send such keepalives. Instead of
all that I simply suggest using the 'ob' parameter for the proxy
URI to indicate that the proxy supports SIP Outbound and all the
keepalive mechanisms defined in SIP Outbound for those transports
the proxy supports according to DNS.

Rationale:

1. SIP Outbound anyway already mandates compliant proxies to
support all keepalive mechanisms (see section 5.4) so there is
no need to define separate flags for each of those mechanisms.
One single flag for Outbound support is sufficient indication.

2. The draft has already defined the 'ob' URI parameter and how the
proxy should use it. My proposal is to use the flag as defined
but additionally to bundle the semantics of separate keepalive
flags to this single 'ob' parameter.

3. The UA could check the presence of 'ob' parameter within the
proxy URI either
a) within its configured outbound-proxy-set; or
b) Path header received within 200 OK to REGISTER
(like suggested in section 8)

4. Simple is better: less flags to be introduced to IANA,
to the URIs or to the implementations. Resulting URIs
would also be shorter with this single and short parameter.


Finally I do not find any value for the 'timed-keepalives'
parameter. It was agreed in IETF68 but I was not attending
the meeting and I have not seen the rationale for it anywhere.
For the proxy point of view what is the difference whether or
not the proxy URI contains this parameter ? If the parameter
is within the URI, the proxy can be sure that it receives
the keepalives with intervals defined in the spec but otherwise
the UA could select longer intervals. However the spec does not
specify any actions for the proxy to check how often it receives
the keepalive messages so what is the point to have such a URI
parameter ? Instead of that I would suggest dropping this
parameter and either:

a) mandate the UA always to use timers as defined in the draft
or
b) let the UA always to choose any timer values it wants to use
and make the timer values in the draft as recommendations

Option b) could be better if the UA later on has some
mechanism (like STUN extension etc.) to ask the middleboxes
to adjust their timer behaviour.


Example of URIs for a proxy supporting all keepalive methods:

Outbound-09:
sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob

My proposal:
sip:pri.example.com;lr;ob

Just guess why I prefer the latter ;-) Any comments ?

Regards,

Erkki


_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

Shape Yahoo! in your own image. Join our Network Research Panel today! --0-2087879867-1183042122=:68561-- --===============1581726491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1581726491==-- From sip-bounces@ietf.org Thu Jun 28 14:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3z9B-0004my-DD; Thu, 28 Jun 2007 14:55:17 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3z99-0004mm-Fb for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 14:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3z99-0004me-5n for sip@ietf.org; Thu, 28 Jun 2007 14:55:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3z8z-0006eW-SB for sip@ietf.org; Thu, 28 Jun 2007 14:55:15 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I3z8x-00081h-Ek; Thu, 28 Jun 2007 13:55:03 -0500 In-Reply-To: <9D18525F6EF33947BDEF23374EF26C7A06CD97@stntexch11.cis.neustar.com> References: <9D18525F6EF33947BDEF23374EF26C7A06CD97@stntexch11.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP Date: Thu, 28 Jun 2007 13:54:56 -0500 To: "Peterson, Jon" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 27, 2007, at 3:39 PM, Peterson, Jon wrote: > > I also have to admit I'm a skeptical. Various forms of non-hop-by- > hop authentication with certificates were enabled by S/MIME, > especially in conjunction with entities like AIBs. As far as I'm > concerned, the mechanics have had their day in court, and it didn't > go well. We can grapple with the syntax to try to find something > slightly different that will actually appeal to the implementation > community, but I don't think the problem was that we had the wrong > syntax. I have a hunch that the problem related to the S/MIME and AIB dependency. Anybody ever see an implementation of this stuff in SIP that worked? -- 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 sip-bounces@ietf.org Thu Jun 28 15:05:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3zIs-0006Hf-W1; Thu, 28 Jun 2007 15:05:18 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I3zIq-0005zg-Fb for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 15:05:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3zIq-0005xw-1n for sip@ietf.org; Thu, 28 Jun 2007 15:05:16 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3zDm-0000Ar-Ui for sip@ietf.org; Thu, 28 Jun 2007 15:00:30 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I3zDm-00082d-DK; Thu, 28 Jun 2007 14:00:02 -0500 In-Reply-To: <4682CBF1.9000401@cisco.com> References: <5D1A7985295922448D5550C94DE29180012C97CA@DEEXC1U01.de.lucent.com> <46819819.5080107@cisco.com> <4681DA3C.8090607@softarmor.com> <4682CBF1.9000401@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80A444DE-0EFE-4AD9-A340-DB1AD43DE734@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP Date: Thu, 28 Jun 2007 13:59:54 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IETF SIP List , "DRAGE, Keith \(Keith\)" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 27, 2007, at 3:43 PM, Jonathan Rosenberg wrote: > > > Dean Willis wrote: > >> Jonathan Rosenberg wrote: >>> Well, I'm going to be contrarian here. I'm not convinced that >>> this is >>> needed. >>> >>> I think certificate based authentication is a great idea. >>> However, I am >>> not sure I understand why TLS is not an appropriate solution. >>> >> I think it is very simple why TLS is not appropriate. TLS doesn't >> work >> across proxies, and would therefore require the edge proxy to do >> authentication. > > So what? I think thats what ought to happen. I'd like to see some > specific use cases where this can't work with the edge proxy > performing the authentication. Keep in mind, we are talking about > *certificate* authentication; that doesn't (by definition) required > any kind of pre-arranged secret - only a common root CA. My edge proxy might be provided by MCI, but I might be using a chat service from another provider overseas. This other provider might be willing to trust the certificate for authentication (given that I have a signed cert from MCI, who in turn has a signed CA cert from a recognized op-level CA). However, the chat provider might not be willing to just accept P-Asserted-Identity from MCI as an authentication mechanism, since said provider does not have a trusted peering arrangement with MCI and therefore ANYBODY could spoof my P- Asserted-Identity. -- 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 sip-bounces@ietf.org Thu Jun 28 15:10:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3zOJ-0003RW-NL; Thu, 28 Jun 2007 15:10:55 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I1HS7-00018N-WD for sip-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 03:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1HS7-00018F-Iu for sip@ietf.org; Thu, 21 Jun 2007 03:51:39 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1HS6-00058h-Na for sip@ietf.org; Thu, 21 Jun 2007 03:51:39 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l5L7paIL026615 for ; Thu, 21 Jun 2007 09:51:36 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l5L7peEh004215 for ; Thu, 21 Jun 2007 09:51:40 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 09:51:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jun 2007 09:51:24 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B0179715F@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments draft-ietf-sip-saml-02 Thread-Index: Acez2PdAJq0jGVAuR9if7fPos6q2EQ== From: "Willekens, Marc" To: X-OriginalArrivalTime: 21 Jun 2007 07:51:37.0292 (UTC) FILETIME=[FED358C0:01C7B3D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f X-Mailman-Approved-At: Thu, 28 Jun 2007 15:10:54 -0400 Subject: [Sip] Comments draft-ietf-sip-saml-02 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1700901586==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1700901586== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B3D8.FE445782" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B3D8.FE445782 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, here are some comments to the draft: = http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt =20 =20 a) Comments [Page 2], Abstract Can you add a reference to the corresponding RFC number? (RFC4474, = RFC4484?) =20 [Page 3], Introduction Is this document only about assertion for the authorization or also for = the authentication? =20 [Page 7], 3.1. SAML Assertion ...including issuer, timestamp (IssueInstant) and subject ... =20 [Page 9], 4. Specification scope ...SIP profile and binding ... =20 [Page 12] Domain name for Alice: example.com or foo.com?? (same comment for other = figures) Authentication service or Assertion service or both? =20 [Page 13], 6.1. Assertion Fetch profile Is this the only planned profile or will other profiles be defined and = added later? Will there also be a push based model? Will it then be = "pushed" as part of the SIP message?=20 =20 [Page 13], 6.1.1. URN What's the current consensus for the urn? =20 [Page 17], 6.1.3. ...sender and Authentication service (AS) may be separate or... ??? How will the AS and sender be combined? Should it not be Authentication = or Assertion service which can be combined? =20 [Page 22], 6.1.4.1.4. AttributeStatement is indicated. But what about Authentication and = Authorization Decision statement?=20 =20 [Page 23], Step 3, TODO I think it's always good to indicate problems with the assertion. =20 [Page36], Figure 5 should de saml: keyword not be added for the XML elements? saml:Assertion,=20 =20 [Page30] Security considerations Is it possible to redirect messages to an own authentication service by = manipulating the end-device? How can the called party trust the = authentication service assigned by the caller? =20 [Page31] This RFC draft talks about assertions. But how can an identity be = asserted only by considering a device, e.g. in case a device is stolen = or temporary used by someone else? At VON 2000, H. Schulzrinne has = already indicated that something as fingerprint has to be added for a = device with a changing set of owners.=20 =20 =20 b) Typos [Page 11], 5, =A71: ...because the those -> because those:=20 [Page 14], 5.1.2: ...Although this profile is overview ....->=20 [Page 21], 5.1.4.1: ....requirments .... ->=20 [Page 40], Appendix A: ...addtional. ->=20 =20 With best regards, Marc Willekens. ------_=_NextPart_001_01C7B3D8.FE445782 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, here are some comments to the draft: = h= ttp://www.ietf.org/internet-drafts/draft-ietf-sip-saml-02.txt<= /B>

 

 

a) = Comments

[Page = 2],=20 Abstract

Can = you add a=20 reference to the corresponding RFC number? (RFC4474, = RFC4484?)

 

[Page = 3],=20 Introduction

Is = this document=20 only about assertion for the authorization or also for the=20 authentication?

 

[Page = 7], 3.1. SAML=20 Assertion

...including issuer,=20 timestamp (IssueInstant) and subject ...

 

[Page = 9], 4.=20 Specification scope

...SIP = profile and=20 binding ...

 

[Page = 12]

Domain = name for=20 Alice:=20 example.com or foo.com?? (same comment for other figures)

Authentication=20 service or Assertion service or both?

 

[Page = 13], 6.1.=20 Assertion Fetch profile

Is = this the only=20 planned profile or will other profiles be defined and added later?  Will there also be a push = based model?=20 Will it then be "pushed" as part of the SIP message?

 

[Page = 13], 6.1.1.=20 URN

What's = the current=20 consensus for the urn?

 

[Page = 17],=20 6.1.3.

...sender and=20 Authentication service (AS) may be separate or... ???

How = will the AS and=20 sender be combined? Should it not be Authentication or Assertion service = which=20 can be combined?

 

[Page = 22],=20 6.1.4.1.4.

AttributeStatement=20 is indicated. But what about Authentication and Authorization Decision=20 statement?

 

[Page = 23], Step 3,=20 TODO

I = think it's always=20 good to indicate problems with the assertion.

 

[Page36], Figure=20 5

should = de saml:=20 keyword not be added for the XML elements?

saml:Assertion,=20

 

[Page30] Security=20 considerations

Is it = possible to=20 redirect messages to an own authentication service by manipulating the=20 end-device? How can the called party trust the authentication service = assigned=20 by the caller?

 

[Page31]

This = RFC draft talks=20 about assertions. But how can an identity be asserted only by = considering a=20 device, e.g. in case a device is stolen or temporary used by someone = else? At=20 VON 2000, H. Schulzrinne has already indicated that something as = fingerprint has=20 to be added for a device with a changing set of owners.

 

 

b)=20 Typos

[Page = 11], 5, =A71:=20 ...because the those -> because those:

[Page = 14], 5.1.2:=20 ...Although this profile is overview ....->

[Page 21], 5.1.4.1: = ....requirments=20 .... ->

[Page 40], Appendix A: = ...addtional.=20 ->

 

With=20 best regards,

Marc=20 Willekens.

------_=_NextPart_001_01C7B3D8.FE445782-- --===============1700901586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1700901586==-- From sip-bounces@ietf.org Thu Jun 28 16:32:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40fa-0006Ev-8v; Thu, 28 Jun 2007 16:32:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I40fY-0006El-Dx for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 16:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40fY-0006EY-40 for sip@ietf.org; Thu, 28 Jun 2007 16:32:48 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40ee-0007GY-Tk for sip@ietf.org; Thu, 28 Jun 2007 16:32:47 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l5SKViQh024525; Thu, 28 Jun 2007 13:31:44 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.5) with ESMTP id l5SKVhdp019100; Thu, 28 Jun 2007 13:31:43 -0700 Received: from 172.24.28.103 ([172.24.28.103]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jun 2007 20:31:42 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 28 Jun 2007 13:31:42 -0700 Subject: Re: [Sip] Certificate authentication in SIP From: Eric Burger To: IETF SIP Message-ID: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace5w1Y9lRGS+CW2EdyWbAAWy4mm/w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Why not SIPPING, the home of requirements? On 6/25/07 6:40 AM, "peter_blatherwick@mitel.com" wrote: > > Sorry, I had missed this going by until someone pointed it out ... > > Basically, I would support this work in SIP WG, which does seem like the right > place at least for requirements (can see where it goes next from there). > >> So can I hear opinions of the WG on: >> >> - whether this represents a problem space that the working >> group >> should draft requirements on? > > SIP WG seems like as good a place as any, at least for requirements. > >> >> - whether the problem space exists but is something slightly >> different, and if so what is that problem space? > > Yes, the problem space exists. > >> >> - whether there is a more general problem that the security >> area >> should be addressing, rather than the SIP group addressing something >> specific? > > Develop the *requirements* first, then ask this question. A worthy question > for this list would be whether the requirements should expand to use cases > beyond Registrar interactions (e.g to Invite, Subscribe/Notify, or to > streaming uses, etc). Of course, the Security Area should be involved > regardless, esp at solution time. > >> >> - based on your answers to the first three questions, whether >> this >> draft is essentially in the right direction to be adopted as the WG >> draft assuming we create the charter item, or whether we need to seek >> some other input draft? > > I believe it is close, modulo wondering about expansion beyond Register as > above. (Could dicker over details...) > >> >> - and finally, whether (assuming we go ahead with this work) >> there >> is any work in any other IETF WG that we should take account of? > > Dunno. > > -- Peter Blatherwick > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Wednesday, June 13, 2007 9:58 AM > > To: IETF SIP List > > Subject: [Sip] Certificate authentication in SIP > > (As WG chair) > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth-03 > > .txt > > Describes a set of requirements for: > > This document defines requirements for adding certificate > authentication to the Session Initiation Protocol (SIP). This > document is being presented with the intention of providing clear > requirements to any potential solutions specifying certificate > authentication within SIP networks. Supporting certificate > authentication in SIP would provide strong authentication and > increase the types of possible deployment scenarios. > > (Before we go any further, please forget all about the solutions > document - that comes later and we are not dealing with it now) > > We need to decide whether there is support for a body of work in this > area, and therefore whether we should charter some requirements work in > the SIP WG. > > (Because this is security related we have agreed that SIP does the > requirements drafting and not SIPPING) > > So can I hear opinions of the WG on: > > - whether this represents a problem space that the working > group > should draft requirements on? > > - whether the problem space exists but is something slightly > different, and if so what is that problem space? > > - whether there is a more general problem that the security > area > should be addressing, rather than the SIP group addressing something > specific? > > - based on your answers to the first three questions, whether > this > draft is essentially in the right direction to be adopted as the WG > draft assuming we create the charter item, or whether we need to seek > some other input draft? > > - and finally, whether (assuming we go ahead with this work) > there > is any work in any other IETF WG that we should take account of? > > > Regards > > Keith > > > > Regards > > Keith > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > Use sip-implementors at cs.columbia.edu for questions on current sip > Use sipping at ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 28 21:14:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4540-000306-Db; Thu, 28 Jun 2007 21:14:20 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I453y-0002zl-Od for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 21:14:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I453y-0002zY-Di for sip@ietf.org; Thu, 28 Jun 2007 21:14:18 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I453y-0002Ld-3a for sip@ietf.org; Thu, 28 Jun 2007 21:14:18 -0400 Received: from [192.168.2.99] (adsl-67-112-220-125.dsl.sntc01.pacbell.net [67.112.220.125]) (authenticated bits=0) by vicuna.estacado.net (8.14.1/8.14.1) with ESMTP id l5T1DlSK030808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2007 20:13:52 -0500 (CDT) (envelope-from rjsparks@estacado.net) In-Reply-To: <4683B00B.3060700@cisco.com> References: <4683B00B.3060700@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34A45E00-C4EF-4C27-A8E8-45E94D36549B@estacado.net> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Changes to the INVITE transaction to address bug 769 Date: Thu, 28 Jun 2007 18:13:46 -0700 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: SIP IETF X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Yeah - stateless proxies have a similar admission policy problem for responses as they are defined in 3261. You can address that (I think) without requiring them to keep transaction state though (I think). It would involve something along the lines of providing bits to themselves that they see in the response that lets them know this response corresponds to a request they actually forwarded recently (it would require them to have a clock to reference, but they wouldn't have to keep timers). RjS On Jun 28, 2007, at 5:56 AM, Paul Kyzivat wrote: > Robert, > > I seem to recall from long ago that one reason for forwarding > strays was to support restart or failover of a proxy, where > internal state of the failed proxy is not preserved. As I recall, > the expectation was that while things might not work as well as if > the failure had not happened, the situation would be better than if > these messages were not forwarded. > > This is only a vague memory, so it may not be right. But if it is, > won't the proposed changes break that? Does it matter? > > Also, while I see some logic in not forwarding strays for the > reasons stated in the draft, if that is a problem that needs to be > solved, shouldn't stateless proxies also be banned? > > Paul > > Robert Sparks wrote: >> Everyone - >> I've put together a proposal for addressing the spec bug captured at >> http://bugs.sipit.net/show_bug.cgi?id=769 >> Please read through >> http://www.ietf.org/internet-drafts/draft-sparks-sip-invfix-00.txt >> and comment. >> RjS >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Jun 28 21:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45MA-00017E-Kh; Thu, 28 Jun 2007 21:33:06 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I45M9-00016b-2J for sip-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 21:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I45M8-00016I-FN; Thu, 28 Jun 2007 21:33:04 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I45Lz-0007eK-SM; Thu, 28 Jun 2007 21:33:04 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKD007OGIXERB@szxga03-in.huawei.com>; Fri, 29 Jun 2007 09:32:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKD00HJUIXD1S@szxga03-in.huawei.com>; Fri, 29 Jun 2007 09:32:01 +0800 (CST) Received: from s32328b ([10.70.108.124]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKD009EJIX9CZ@szxml03-in.huawei.com>; Fri, 29 Jun 2007 09:32:01 +0800 (CST) Date: Fri, 29 Jun 2007 09:31:56 +0800 From: Qian Sun To: 'sipping' Message-id: <00b801c7b9ed$4808ea40$7c6c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT Thread-index: Ace57UfektLmy6i7QTqO+DlAGe9GbQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'SIP IETF' Subject: [Sip] I-D: Multiple Reply in the Session Initiation Protocol X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Hi, I have just submitted a draft discussing multiple reply-to addresses. The I-D can be found at http://www.ietf.org/internet-drafts/draft-sun-sipping-multiple-reply-00.txt Abstract: This document defines extensions to the Reply-To header field for MESSAGE so that it can be used to specify multiple addresses as the target of reply MESSAGE. These extensions include the use of pointers to Uniform Resource Identifier (URI)-lists in the Reply-To header field and the "multiple-reply" SIP option-tag. Comments welcome! Cheers, Qian _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 00:50:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I48RC-0006bL-MJ; Fri, 29 Jun 2007 00:50:30 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I48RA-0006aZ-Ie for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 00:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I48R9-0006Zr-My for sip@ietf.org; Fri, 29 Jun 2007 00:50:28 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I48Qn-0006oz-2D for sip@ietf.org; Fri, 29 Jun 2007 00:50:27 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I48Ql-0000CO-GN; Thu, 28 Jun 2007 23:50:03 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18B3D205-82A4-40FA-B85A-14F41B2C0339@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Certificate authentication in SIP Date: Thu, 28 Jun 2007 23:49:55 -0500 To: Eric Burger X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: IETF SIP , Keith Drage X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Jun 28, 2007, at 3:31 PM, Eric Burger wrote: > Why not SIPPING, the home of requirements? The current policy of task division puts "security" in SIP instead of SIPPING. Although the task allocation is quite arguable on this specific exercise. -- 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 sip-bounces@ietf.org Fri Jun 29 02:29:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49yk-0006Dm-CH; Fri, 29 Jun 2007 02:29:14 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I49yi-0006AZ-Ml for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 02:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49yh-00064b-I6 for sip@ietf.org; Fri, 29 Jun 2007 02:29:11 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I49ya-0007jI-0O for sip@ietf.org; Fri, 29 Jun 2007 02:29:11 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l5T6SWDR023004; Fri, 29 Jun 2007 01:28:54 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 01:28:53 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:28:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Fri, 29 Jun 2007 08:28:51 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001371304@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace5w1Y9lRGS+CW2EdyWbAAWy4mm/wAU1GfA References: From: "DRAGE, Keith \(Keith\)" To: "Eric Burger" , "IETF SIP" X-OriginalArrivalTime: 29 Jun 2007 06:28:51.0341 (UTC) FILETIME=[C2315BD0:01C7BA16] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org >From the original mail: > (Because this is security related we have agreed that SIP does the=20 > requirements drafting and not SIPPING) > I did agree this with the SIPPING chairs before sending the mail out. Keith=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@bea.com]=20 > Sent: Thursday, June 28, 2007 9:32 PM > To: IETF SIP > Cc: DRAGE, Keith (Keith) > Subject: Re: [Sip] Certificate authentication in SIP >=20 > Why not SIPPING, the home of requirements? >=20 >=20 > On 6/25/07 6:40 AM, "peter_blatherwick@mitel.com" > wrote: >=20 > >=20 > > Sorry, I had missed this going by until someone pointed it out ... > >=20 > > Basically, I would support this work in SIP WG, which does=20 > seem like=20 > > the right place at least for requirements (can see where it=20 > goes next from there). > >=20 > >> So can I hear opinions of the WG on: > >>=20 > >> - whether this represents a problem space=20 > that the working > >> group > >> should draft requirements on? > >=20 > > SIP WG seems like as good a place as any, at least for requirements. > >=20 > >>=20 > >> - whether the problem space exists but is=20 > something slightly > >> different, and if so what is that problem space? > >=20 > > Yes, the problem space exists. > >=20 > >>=20 > >> - whether there is a more general problem=20 > that the security > >> area > >> should be addressing, rather than the SIP group addressing=20 > something=20 > >> specific? > >=20 > > Develop the *requirements* first, then ask this question. A worthy=20 > > question for this list would be whether the requirements=20 > should expand=20 > > to use cases beyond Registrar interactions (e.g to Invite,=20 > > Subscribe/Notify, or to streaming uses, etc). Of course,=20 > the Security=20 > > Area should be involved regardless, esp at solution time. > >=20 > >>=20 > >> - based on your answers to the first three=20 > questions, whether > >> this > >> draft is essentially in the right direction to be adopted=20 > as the WG=20 > >> draft assuming we create the charter item, or whether we=20 > need to seek=20 > >> some other input draft? > >=20 > > I believe it is close, modulo wondering about expansion beyond=20 > > Register as above. (Could dicker over details...) > >=20 > >>=20 > >> - and finally, whether (assuming we go=20 > ahead with this work) > >> there > >> is any work in any other IETF WG that we should take account of? > >=20 > > Dunno. =20 > >=20 > > -- Peter Blatherwick > >=20 > >=20 > > -----Original Message----- > >=20 > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >=20 > > Sent: Wednesday, June 13, 2007 9:58 AM > >=20 > > To: IETF SIP List > >=20 > > Subject: [Sip] Certificate authentication in SIP > >=20 > > (As WG chair) > >=20 > >=20 > http://www.ietf.org/internet-drafts/draft-dotson-sip-certificate-auth- > > 03=20 > >=20 > > -03> > > .txt > >=20 > > Describes a set of requirements for: > >=20 > > This document defines requirements for adding certificate > > authentication to the Session Initiation Protocol (SIP). This > > document is being presented with the intention of providing clear > > requirements to any potential solutions specifying certificate > > authentication within SIP networks. Supporting certificate > > authentication in SIP would provide strong authentication and > > increase the types of possible deployment scenarios. > >=20 > > (Before we go any further, please forget all about the solutions=20 > > document - that comes later and we are not dealing with it now) > >=20 > > We need to decide whether there is support for a body of=20 > work in this=20 > > area, and therefore whether we should charter some=20 > requirements work=20 > > in the SIP WG. > >=20 > > (Because this is security related we have agreed that SIP does the=20 > > requirements drafting and not SIPPING) > >=20 > > So can I hear opinions of the WG on: > >=20 > > - whether this represents a problem space=20 > that the working > > group > > should draft requirements on? > >=20 > > - whether the problem space exists but is=20 > something slightly > > different, and if so what is that problem space? > >=20 > > - whether there is a more general problem=20 > that the security > > area > > should be addressing, rather than the SIP group addressing=20 > something=20 > > specific? > >=20 > > - based on your answers to the first three=20 > questions, whether > > this > > draft is essentially in the right direction to be adopted as the WG=20 > > draft assuming we create the charter item, or whether we=20 > need to seek=20 > > some other input draft? > >=20 > > - and finally, whether (assuming we go ahead=20 > with this work) > > there > > is any work in any other IETF WG that we should take account of? > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > >=20 > > Regards > >=20 > > Keith > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors at cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping at ietf.org for new developments on the application of sip > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 >=20 > Notice: This email message, together with any attachments,=20 > may contain information of BEA Systems, Inc., its=20 > subsidiaries and affiliated entities, that may be=20 > confidential, proprietary, copyrighted and/or legally=20 > privileged, and is intended solely for the use of the=20 > individual or entity named in this message. If you are not=20 > the intended recipient, and have received this message in=20 > error, please immediately return this by email and then delete it. >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 04:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BPj-0000sr-5F; Fri, 29 Jun 2007 04:01:11 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4BPh-0000sI-QY for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 04:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BPh-0000rd-FZ for sip@ietf.org; Fri, 29 Jun 2007 04:01:09 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4BOm-0000kO-U3 for sip@ietf.org; Fri, 29 Jun 2007 04:01:09 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Jun 2007 01:00:12 -0700 X-IronPort-AV: i="4.16,474,1175497200"; d="scan'208"; a="174242733:sNHT74473362" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5T80Cf1014540; Fri, 29 Jun 2007 01:00:12 -0700 Received: from dwingwxp (sjc-vpn5-1794.cisco.com [10.21.95.2]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5T80Amo015695; Fri, 29 Jun 2007 08:00:11 GMT From: "Dan Wing" To: "'Peterson, Jon'" , "'Jonathan Rosenberg'" , "'DRAGE, Keith \(Keith\)'" Subject: RE: [Sip] Certificate authentication in SIP Date: Fri, 29 Jun 2007 01:00:09 -0700 Message-ID: <11b101c7ba23$84df31f0$dd93150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlgAEob+ZA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <9D18525F6EF33947BDEF23374EF26C7A06CD97@stntexch11.cis.neustar.com> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5853; t=1183104012; x=1183968012; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Sip]=20Certificate=20authentication=20in=20SIP |Sender:=20; bh=+SXeHDcN0vHBWGbDnxgXdrskNNrN1nyL8F/qwBAWz+U=; b=ronYwWkrH4hFUFrHULTAqlcMqjLKnrFmVxZXKg9ekTF1QAvtTjK3pwKiYSXCVmOvrJPAy850 y2pkBpO1Zhcfc2zNxKVWu+9pgMp3wwU0K0vpIAyyCNLpxaxX/FygXwL5; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: 'IETF SIP List' X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org The certificate authentication would be used in place of today's Digest authentication. S/MIME and AIB were never used where Digest is used; I don't see the relationship between what's on the table now and S/MIME and AIB -- except that they are two certificate-based authentication schemes, S/MIME and AIB are both intended to work end-to-end (between the two SIP peers desiring to establish communication with each other), whereas the certificate authentication being discussed is to replace ("enhance", whatever word you prefer) the username/password digest authentication. Digest authentication isn't done between peers establishing communication with each other (except in a laboratory environment), but Digest is done to authenticate yourself to a SIP network so you can gain authorization to interact with that SIP network --- and that's what's on the table for certificate authentication. -d > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, June 27, 2007 1:40 PM > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > Cc: IETF SIP List > Subject: RE: [Sip] Certificate authentication in SIP > > > I also have to admit I'm a skeptical. Various forms of > non-hop-by-hop authentication with certificates were enabled > by S/MIME, especially in conjunction with entities like AIBs. > As far as I'm concerned, the mechanics have had their day in > court, and it didn't go well. We can grapple with the syntax > to try to find something slightly different that will > actually appeal to the implementation community, but I don't > think the problem was that we had the wrong syntax. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > Sent: Tuesday, June 26, 2007 3:50 PM > > To: DRAGE, Keith (Keith) > > Cc: IETF SIP List > > Subject: Re: [Sip] Certificate authentication in SIP > > > > > > Well, I'm going to be contrarian here. I'm not convinced > that this is > > needed. > > > > I think certificate based authentication is a great idea. > > However, I am > > not sure I understand why TLS is not an appropriate solution. > > > > DRAGE, Keith (Keith) wrote: > > > > > (As WG chair) > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > te-auth-03 > > > .txt > > > > > > Describes a set of requirements for: > > > > > > This document defines requirements for adding certificate > > > authentication to the Session Initiation Protocol (SIP). This > > > document is being presented with the intention of > providing clear > > > requirements to any potential solutions specifying certificate > > > authentication within SIP networks. Supporting certificate > > > authentication in SIP would provide strong authentication and > > > increase the types of possible deployment scenarios. > > > > > > (Before we go any further, please forget all about the solutions > > > document - that comes later and we are not dealing with it now) > > > > > > We need to decide whether there is support for a body of > > work in this > > > area, and therefore whether we should charter some > > requirements work in > > > the SIP WG. > > > > > > (Because this is security related we have agreed that SIP does the > > > requirements drafting and not SIPPING) > > > > > > So can I hear opinions of the WG on: > > > > > > - whether this represents a problem space that the working group > > > should draft requirements on? > > > > > > - whether the problem space exists but is something slightly > > > different, and if so what is that problem space? > > > > > > - whether there is a more general problem that the security area > > > should be addressing, rather than the SIP group > addressing something > > > specific? > > > > > > - based on your answers to the first three questions, whether this > > > draft is essentially in the right direction to be adopted > as the WG > > > draft assuming we create the charter item, or whether we > > need to seek > > > some other input draft? > > > > > > - and finally, whether (assuming we go ahead with this work) there > > > is any work in any other IETF WG that we should take account of? > > > > > > > > > Regards > > > > > > Keith > > > > > > > > > > > > Regards > > > > > > Keith > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.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 sip-bounces@ietf.org Fri Jun 29 08:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Fmx-0004kp-EI; Fri, 29 Jun 2007 08:41:27 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4Fmw-0004kk-CS for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 08:41:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Fmw-0004ka-2p for sip@ietf.org; Fri, 29 Jun 2007 08:41:26 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4FmE-0005sA-Vr for sip@ietf.org; Fri, 29 Jun 2007 08:41:26 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id EABCD329C3; Fri, 29 Jun 2007 12:40:42 +0000 (GMT) Received: from stntexch11.cis.neustar.com ([10.31.13.50]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:40:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Certificate authentication in SIP Date: Fri, 29 Jun 2007 08:40:42 -0400 Message-ID: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com> In-Reply-To: <11b101c7ba23$84df31f0$dd93150a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlgAEob+ZAACTxZgA== From: "Peterson, Jon" To: "Dan Wing" , "Jonathan Rosenberg" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 29 Jun 2007 12:40:42.0841 (UTC) FILETIME=[B4E21490:01C7BA4A] X-Spam-Score: -2.3 (--) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I do think that AIB was (and I stress *was*) potentially a tool that = could be used in place of Digest, for example, for the registration use = case. Nothing about that work limited it to the end-to-end case. Anyway, = the new draft does insist that end-to-end is a requirement. But that's not really material - my note certainly wasn't an attempt to = rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder = that no small part of the reason why those mechanisms didn't set the = world on fire was because of generic certificate enrollment problems, = user mobility requiring mobile certificate management, the = implausibility of certificates with SIP identifiers as subjects, and a = myriad of similar problems that have little to do with whether = authentication is end-to-end or what have you - they are rather rooted = in the easily-underestimated difficulty of managing the relationship = between SIP users, SIP devices, and certificates. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 29, 2007 1:00 AM > To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)' > Cc: 'IETF SIP List' > Subject: RE: [Sip] Certificate authentication in SIP >=20 >=20 > The certificate authentication would be used in place of today's = Digest > authentication. >=20 > S/MIME and AIB were never used where Digest is used; I don't see the > relationship between what's on the table now and S/MIME and=20 > AIB -- except > that they are two certificate-based authentication schemes,=20 > S/MIME and AIB > are both intended to work end-to-end (between the two SIP=20 > peers desiring to > establish communication with each other), whereas the certificate > authentication being discussed is to replace ("enhance",=20 > whatever word you > prefer) the username/password digest authentication. Digest=20 > authentication > isn't done between peers establishing communication with each=20 > other (except > in a laboratory environment), but Digest is done to=20 > authenticate yourself to > a SIP network so you can gain authorization to interact with that SIP > network --- and that's what's on the table for certificate=20 > authentication. >=20 > -d >=20 >=20 > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > > Sent: Wednesday, June 27, 2007 1:40 PM > > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Certificate authentication in SIP > >=20 > >=20 > > I also have to admit I'm a skeptical. Various forms of=20 > > non-hop-by-hop authentication with certificates were enabled=20 > > by S/MIME, especially in conjunction with entities like AIBs.=20 > > As far as I'm concerned, the mechanics have had their day in=20 > > court, and it didn't go well. We can grapple with the syntax=20 > > to try to find something slightly different that will=20 > > actually appeal to the implementation community, but I don't=20 > > think the problem was that we had the wrong syntax. > >=20 > > Jon Peterson > > NeuStar, Inc. > >=20 > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: Tuesday, June 26, 2007 3:50 PM > > > To: DRAGE, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: Re: [Sip] Certificate authentication in SIP > > >=20 > > >=20 > > > Well, I'm going to be contrarian here. I'm not convinced=20 > > that this is=20 > > > needed. > > >=20 > > > I think certificate based authentication is a great idea.=20 > > > However, I am=20 > > > not sure I understand why TLS is not an appropriate solution. > > >=20 > > > DRAGE, Keith (Keith) wrote: > > >=20 > > > > (As WG chair) > > > >=20 > > > >=20 > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > > te-auth-03 > > > > .txt=20 > > > >=20 > > > > Describes a set of requirements for: > > > >=20 > > > > This document defines requirements for adding certificate > > > > authentication to the Session Initiation Protocol=20 > (SIP). This > > > > document is being presented with the intention of=20 > > providing clear > > > > requirements to any potential solutions specifying=20 > certificate > > > > authentication within SIP networks. Supporting certificate > > > > authentication in SIP would provide strong authentication and > > > > increase the types of possible deployment scenarios. > > > >=20 > > > > (Before we go any further, please forget all about the solutions > > > > document - that comes later and we are not dealing with it now) > > > >=20 > > > > We need to decide whether there is support for a body of=20 > > > work in this > > > > area, and therefore whether we should charter some=20 > > > requirements work in > > > > the SIP WG. > > > >=20 > > > > (Because this is security related we have agreed that=20 > SIP does the > > > > requirements drafting and not SIPPING) > > > >=20 > > > > So can I hear opinions of the WG on: > > > >=20 > > > > - whether this represents a problem space that=20 > the working group > > > > should draft requirements on? > > > >=20 > > > > - whether the problem space exists but is=20 > something slightly > > > > different, and if so what is that problem space? > > > >=20 > > > > - whether there is a more general problem that=20 > the security area > > > > should be addressing, rather than the SIP group=20 > > addressing something > > > > specific? > > > >=20 > > > > - based on your answers to the first three=20 > questions, whether this > > > > draft is essentially in the right direction to be adopted=20 > > as the WG > > > > draft assuming we create the charter item, or whether we=20 > > > need to seek > > > > some other input draft? > > > >=20 > > > > - and finally, whether (assuming we go ahead with=20 > this work) there > > > > is any work in any other IETF WG that we should take account of? > > > >=20 > > > >=20 > > > > Regards > > > >=20 > > > > Keith > > > >=20 > > > >=20 > > > >=20 > > > > Regards > > > >=20 > > > > Keith > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip > > > > Use sipping@ietf.org for new developments on the=20 > > application of sip > > > >=20 > > >=20 > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ=20 > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > http://www.cisco.com > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 09:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GdR-0002Ol-Se; Fri, 29 Jun 2007 09:35:41 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4GdQ-0002Nb-RO for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 09:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GdQ-0002NT-Hh for sip@ietf.org; Fri, 29 Jun 2007 09:35:40 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Gck-0000pw-Al for sip@ietf.org; Fri, 29 Jun 2007 09:35:40 -0400 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id l5TDYk2c015192; Fri, 29 Jun 2007 07:34:46 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 29 Jun 2007 07:34:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Certificate authentication in SIP Date: Fri, 29 Jun 2007 07:34:47 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] Certificate authentication in SIP Thread-Index: Ace4SbDXm8unkQ0oRfqVPKlCfnpT+gAsOQlgAEob+ZAACTxZgAAB9SUW References: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com> From: "Sumanth Channabasappa" To: "Peterson, Jon" , "Dan Wing" , "Jonathan Rosenberg" , "DRAGE, Keith (Keith)" X-Approved: ondar X-Spam-Score: 0.6 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685117843==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============0685117843== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA52.42A99197" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA52.42A99197 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, But that's not really material - my note certainly wasn't an attempt to = rekindle or in any way glamorize S/MIME or AIB. It was rather a reminder = that no small part of the reason why those mechanisms didn't set the = world on fire was because of generic certificate enrollment problems, = user mobility requiring mobile certificate management, the = implausibility of certificates with SIP identifiers as subjects, and a = myriad of similar problems that have little to do with whether = authentication is end-to-end or what have you - they are rather rooted = in the easily-underestimated difficulty of managing the relationship = between SIP users, SIP devices, and certificates. [S] Would this not be part of the reason that we want to tackle this = problem? There are large deployments which use certificates successfully = today (such as cable clients). There are potential deployments which = would like to use certificates for authentication in SIP networks, = without a specified explicit way to do this (or perhaps, lack the = understanding). Now, certificate management is a valid concern, and = potentially a hard problem, but that is only one part of the puzzle (and = may not apply to all deployments).=20 =20 I think we should start by identifying the requirements (since there = seems to be some confusion; and the I-D has not been discussed in the = WG) and see if existing or new solutions are required. And if we find = that certificates need some work to support this initiative (e.g., SIP = identifiers as subjects), perhaps we can present some of those = requirements to other WGs. If we find an existing solutions that can be = used, good (and we can document them as such :) ).=20 - s =20 Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Friday, June 29, 2007 1:00 AM > To: Peterson, Jon; 'Jonathan Rosenberg'; 'DRAGE, Keith (Keith)' > Cc: 'IETF SIP List' > Subject: RE: [Sip] Certificate authentication in SIP > > > The certificate authentication would be used in place of today's = Digest > authentication. > > S/MIME and AIB were never used where Digest is used; I don't see the > relationship between what's on the table now and S/MIME and > AIB -- except > that they are two certificate-based authentication schemes, > S/MIME and AIB > are both intended to work end-to-end (between the two SIP > peers desiring to > establish communication with each other), whereas the certificate > authentication being discussed is to replace ("enhance", > whatever word you > prefer) the username/password digest authentication. Digest > authentication > isn't done between peers establishing communication with each > other (except > in a laboratory environment), but Digest is done to > authenticate yourself to > a SIP network so you can gain authorization to interact with that SIP > network --- and that's what's on the table for certificate > authentication. > > -d > > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, June 27, 2007 1:40 PM > > To: Jonathan Rosenberg; DRAGE, Keith (Keith) > > Cc: IETF SIP List > > Subject: RE: [Sip] Certificate authentication in SIP > > > > > > I also have to admit I'm a skeptical. Various forms of > > non-hop-by-hop authentication with certificates were enabled > > by S/MIME, especially in conjunction with entities like AIBs. > > As far as I'm concerned, the mechanics have had their day in > > court, and it didn't go well. We can grapple with the syntax > > to try to find something slightly different that will > > actually appeal to the implementation community, but I don't > > think the problem was that we had the wrong syntax. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > > > Sent: Tuesday, June 26, 2007 3:50 PM > > > To: DRAGE, Keith (Keith) > > > Cc: IETF SIP List > > > Subject: Re: [Sip] Certificate authentication in SIP > > > > > > > > > Well, I'm going to be contrarian here. I'm not convinced > > that this is > > > needed. > > > > > > I think certificate based authentication is a great idea. > > > However, I am > > > not sure I understand why TLS is not an appropriate solution. > > > > > > DRAGE, Keith (Keith) wrote: > > > > > > > (As WG chair) > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-dotson-sip-certifica > > > te-auth-03 > > > > .txt > > > > > > > > Describes a set of requirements for: > > > > > > > > This document defines requirements for adding certificate > > > > authentication to the Session Initiation Protocol > (SIP). This > > > > document is being presented with the intention of > > providing clear > > > > requirements to any potential solutions specifying > certificate > > > > authentication within SIP networks. Supporting certificate > > > > authentication in SIP would provide strong authentication and > > > > increase the types of possible deployment scenarios. > > > > > > > > (Before we go any further, please forget all about the solutions > > > > document - that comes later and we are not dealing with it now) > > > > > > > > We need to decide whether there is support for a body of > > > work in this > > > > area, and therefore whether we should charter some > > > requirements work in > > > > the SIP WG. > > > > > > > > (Because this is security related we have agreed that > SIP does the > > > > requirements drafting and not SIPPING) > > > > > > > > So can I hear opinions of the WG on: > > > > > > > > - whether this represents a problem space that > the working group > > > > should draft requirements on? > > > > > > > > - whether the problem space exists but is > something slightly > > > > different, and if so what is that problem space? > > > > > > > > - whether there is a more general problem that > the security area > > > > should be addressing, rather than the SIP group > > addressing something > > > > specific? > > > > > > > > - based on your answers to the first three > questions, whether this > > > > draft is essentially in the right direction to be adopted > > as the WG > > > > draft assuming we create the charter item, or whether we > > > need to seek > > > > some other input draft? > > > > > > > > - and finally, whether (assuming we go ahead with > this work) there > > > > is any work in any other IETF WG that we should take account of? > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, NJ > > > 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: =20 > (973) 952-5050 > > > http://www.jdrosen.net = PHONE: > (973) 952-5000 > > > http://www.cisco.com =20 > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ------_=_NextPart_001_01C7BA52.42A99197 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Certificate authentication in = SIP=0A= =0A= =0A= =0A=
=0A=
Jon,
=0A=


But that's not really material - = my note certainly wasn't an attempt to rekindle or in any way glamorize = S/MIME or AIB. It was rather a reminder that no small part of the reason = why those mechanisms didn't set the world on fire was because of generic = certificate enrollment problems, user mobility requiring mobile = certificate management, the implausibility of certificates with SIP = identifiers as subjects, and a myriad of similar problems that have = little to do with whether authentication is end-to-end or what have you = - they are rather rooted in the easily-underestimated difficulty of = managing the relationship between SIP users, SIP devices, and = certificates.
[S] Would this not be part of the reason that we want = to tackle this problem? There are large deployments which use = certificates successfully today (such as cable clients). There are = potential deployments which would like to use certificates for = authentication in SIP networks, without a specified explicit way to do = this (or perhaps, lack the understanding). Now, certificate management = is a valid concern, and potentially a hard problem, but that is only one = part of the puzzle (and may not apply to all deployments).
=0A=
 
=0A=
I think we should start by identifying the = requirements (since there seems to be some confusion; and the I-D has = not been discussed in the WG) and see if existing or new solutions are = required. And if we find that certificates need some work to support = this initiative (e.g., SIP identifiers as subjects), perhaps we can = present some of those requirements to other WGs. If we find an existing = solutions that can be used, good (and we can document them as such :) ). =
=0A=

- s

=0A=

 

=0A=

Jon Peterson
NeuStar, Inc.

> = -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> = Sent: Friday, June 29, 2007 1:00 AM
> To: Peterson, Jon; 'Jonathan = Rosenberg'; 'DRAGE, Keith (Keith)'
> Cc: 'IETF SIP List'
> = Subject: RE: [Sip] Certificate authentication in = SIP
>
>
> The certificate authentication would be used = in place of today's Digest
> authentication.
>
> = S/MIME and AIB were never used where Digest is used; I don't see = the
> relationship between what's on the table now and S/MIME = and
> AIB -- except
> that they are two certificate-based = authentication schemes,
> S/MIME and AIB
> are both intended = to work end-to-end (between the two SIP
> peers desiring = to
> establish communication with each other), whereas the = certificate
> authentication being discussed is to replace = ("enhance",
> whatever word you
> prefer) the = username/password digest authentication.  Digest
> = authentication
> isn't done between peers establishing = communication with each
> other (except
> in a laboratory = environment), but Digest is done to
> authenticate yourself = to
> a SIP network so you can gain authorization to interact with = that SIP
> network --- and that's what's on the table for = certificate
> authentication.
>
> = -d
>
>
> > -----Original Message-----
> > = From: Peterson, Jon [mailto:jon.peterson@neustar.biz<= /A>]
> > Sent: Wednesday, June 27, 2007 1:40 PM
> > = To: Jonathan Rosenberg; DRAGE, Keith (Keith)
> > Cc: IETF SIP = List
> > Subject: RE: [Sip] Certificate authentication in = SIP
> >
> >
> > I also have to admit I'm a = skeptical. Various forms of
> > non-hop-by-hop authentication = with certificates were enabled
> > by S/MIME, especially in = conjunction with entities like AIBs.
> > As far as I'm = concerned, the mechanics have had their day in
> > court, and = it didn't go well. We can grapple with the syntax
> > to try to = find something slightly different that will
> > actually appeal = to the implementation community, but I don't
> > think the = problem was that we had the wrong syntax.
> >
> > Jon = Peterson
> > NeuStar, Inc.
> >
> > > = -----Original Message-----
> > > From: Jonathan Rosenberg = [mailto:jdrosen@cisco.com]
> = > > Sent: Tuesday, June 26, 2007 3:50 PM
> > > To: = DRAGE, Keith (Keith)
> > > Cc: IETF SIP List
> > = > Subject: Re: [Sip] Certificate authentication in SIP
> > = >
> > >
> > > Well, I'm going to be = contrarian here. I'm not convinced
> > that this is
> = > > needed.
> > >
> > > I think = certificate based authentication is a great idea.
> > > = However, I am
> > > not sure I understand why TLS is not an = appropriate solution.
> > >
> > > DRAGE, Keith = (Keith) wrote:
> > >
> > > > (As WG = chair)
> > > >
> > > >
> > > = h= ttp://www.ietf.org/internet-drafts/draft-dotson-sip-certifica
>= > > te-auth-03
> > > > .txt
> > > = >
> > > > Describes a set of requirements for:
> = > > >
> > > >    This document = defines requirements for adding certificate
> > > = >    authentication to the Session Initiation = Protocol
> (SIP).  This
> > > = >    document is being presented with the intention = of
> > providing clear
> > > >    = requirements to any potential solutions specifying
> = certificate
> > > >    authentication = within SIP networks.  Supporting certificate
> > > = >    authentication in SIP would provide strong = authentication and
> > > >    increase the = types of possible deployment scenarios.
> > > >
> = > > > (Before we go any further, please forget all about the = solutions
> > > > document - that comes later and we are = not dealing with it now)
> > > >
> > > > = We need to decide whether there is support for a body of
> > = > work in this
> > > > area, and therefore whether we = should charter some
> > > requirements work in
> > = > > the SIP WG.
> > > >
> > > > = (Because this is security related we have agreed that
> SIP does = the
> > > > requirements drafting and not = SIPPING)
> > > >
> > > > So can I hear = opinions of the WG on:
> > > >
> > > > = -       whether this represents a problem = space that
> the working group
> > > > should draft = requirements on?
> > > >
> > > > = -       whether the problem space exists = but is
> something slightly
> > > > different, and = if so what is that problem space?
> > > >
> > = > > -       whether there is a more = general problem that
> the security area
> > > > = should be addressing, rather than the SIP group
> > addressing = something
> > > > specific?
> > > = >
> > > > -       based = on your answers to the first three
> questions, whether = this
> > > > draft is essentially in the right direction = to be adopted
> > as the WG
> > > > draft = assuming we create the charter item, or whether we
> > > = need to seek
> > > > some other input draft?
> > = > >
> > > > -       = and finally, whether (assuming we go ahead with
> this work) = there
> > > > is any work in any other IETF WG that we = should take account of?
> > > >
> > > = >
> > > > Regards
> > > >
> > = > > Keith
> > > >
> > > >
> = > > >
> > > > Regards
> > > = >
> > > > Keith
> > > >
> > = > >
> > > > = _______________________________________________
> > > > = Sip mailing list  https://www1.ietf.org= /mailman/listinfo/sip
> > > > This list is for NEW = development of the core SIP 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.           &n= bsp;       600 Lanidex Plaza
> > = > Cisco = Fellow           &= nbsp;           &n= bsp;           = Parsippany, NJ
> > > 07054-2711
> > > Cisco = Systems
> > > = jdrosen@cisco.com         &n= bsp;           &nb= sp;        FAX:  
> = (973) 952-5050
> > > http://www.jdrosen.net  &n= bsp;           &nb= sp;          PHONE:
> = (973) 952-5000
> > > http://www.cisco.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

 ------_=_NextPart_001_01C7BA52.42A99197-- --===============0685117843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0685117843==-- From sip-bounces@ietf.org Fri Jun 29 10:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HdX-0000dF-K8; Fri, 29 Jun 2007 10:39:51 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4HdV-0000d3-PU for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 10:39:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HdV-0000cq-FN for sip@ietf.org; Fri, 29 Jun 2007 10:39:49 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4HdV-0007by-1T for sip@ietf.org; Fri, 29 Jun 2007 10:39:49 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5TEbfUo015741; Fri, 29 Jun 2007 09:37:46 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5TEbIa29362; Fri, 29 Jun 2007 09:37:18 -0500 (CDT) Message-ID: <4685191E.4060903@alcatel-lucent.com> Date: Fri, 29 Jun 2007 09:37:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sumanth Channabasappa Subject: Re: [Sip] Certificate authentication in SIP References: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com> <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: IETF SIP List , ietf-pkix@imc.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Sumanth Channabasappa wrote: > And if we find that certificates need some work to support this > initiative (e.g., SIP identifiers as subjects), perhaps we can > present some of those requirements to other WGs. If we find an > existing solutions that can be used, good (and we can document them > as such :) ). Scott Lawrence and I have spent some time on this issue, i.e., SIP identifiers as subjects in X.509 certificates. The latest version of the draft that includes pkix WG comments from Prague and the comments of the sip WG ADs and others was posted last week to the archives, and is available at http://tools.ietf.org/html/draft-gurbani-sip-domain-certs-05 Comments on this version would be extremely helpful. Thanks. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 10:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HgZ-0005lr-2w; Fri, 29 Jun 2007 10:42:59 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4HgW-0005lJ-Qs for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 10:42:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4HgW-0005lB-HJ for sip@ietf.org; Fri, 29 Jun 2007 10:42:56 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Hg2-00060H-Ni for sip@ietf.org; Fri, 29 Jun 2007 10:42:56 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4Hg2-0000xY-CU for sip@ietf.org; Fri, 29 Jun 2007 09:42:26 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP From: Dean Willis Date: Fri, 29 Jun 2007 09:42:06 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] WGLC for draft-ietf-sip-sips-05.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm pleased to announce that the authors think that the SIPS draft is ready for working group last call. This draft has had the privilege of more review prior to WGLC than most of our other efforts, so perhaps it won't be too controversial. Please make a final read through the draft and bring any comments back to this list. I'd like to conclude this WGLC by July 16, 2007, so get your comments back in by then. And I'll plan to put some discussion time on the agenda in Chicago. Thanks, and have a great weekend. -- Dean as co-chair and shepherd for draft-ietf-sip-sips-05.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 11:56:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4IpU-0005Go-Ks; Fri, 29 Jun 2007 11:56:16 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4IpT-0005Fy-87 for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 11:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4IpS-0005Fq-Ul for sip@ietf.org; Fri, 29 Jun 2007 11:56:14 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4IpO-00005a-Am for sip@ietf.org; Fri, 29 Jun 2007 11:56:14 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1183130967!24416409!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19999 invoked from network); 29 Jun 2007 15:29:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 29 Jun 2007 15:29:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l5TFTQ8p018330 for ; Fri, 29 Jun 2007 11:29:27 -0400 Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l5TFTOoM018289 for ; Fri, 29 Jun 2007 11:29:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] New draft modifying RFC 4412 for Responses Date: Fri, 29 Jun 2007 10:29:24 -0500 Message-ID: <28F05913385EAC43AF019413F674A0171246E0B5@OCCLUST04EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] New draft modifying RFC 4412 for Responses Thread-Index: Ace3W2f+6x2g9e7DRLOthcOhgFiGbwDBngVA References: From: "DOLLY, MARTIN C, ATTLABS" To: "Janet P Gunn" , "James M. Polk" X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1370543487==" Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --===============1370543487== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA62.459F18E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA62.459F18E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 Agreed. In addition, not having the RPH in the responses would mean the proxies would have to maintain the state of the RPH value. =20 Martin ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com]=20 In working on specifying and deploying systems that will actually use the RPH with the ets and wps namespaces, we have found several contexts in which the RPH on the response is very useful.=20 1) Error reporting. RFC 4412 does not give clear direction on the treatment of RPH with syntax errors (out of range priority values, duplicate namespaces, etc.) We have found that including the RPH in the 4xx responses is usesful in addressing the errors.=20 2) In our system, we often set the ets RPH (with default priority) based on the "ETS-DN""dialed number" or uri, before authentication and before knowing the correct priority value. Including the RPH in the response is a useful way of conveying the correct priority value back to nodes earlier in the "call flow".=20 3) Similarly, if an RP actor receives a SIP INVITE with the ETS-DN, but no RPH it may, after authenticating the call, include RPH in the responses in order to inform nodes earlier in the call flow that this is a priority call.=20 4) If the RPH is being used to prioritize processing (of both messages and responses) in the SIP user agent, including the RPH in the response allows the receiving RP actor to give the response "ETS treatment" before checking on the "state" of the call. This is particularly relevant when the RP actor itself is congested.=20 Janet ------_=_NextPart_001_01C7BA62.459F18E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
Agreed. In addition, not having the RPH in = the=20 responses would mean the proxies would have to maintain the state of the = RPH=20 value.
 
Martin

From: Janet P Gunn = [mailto:jgunn6@csc.com]=20
In working on = specifying=20 and deploying systems that will actually use the RPH with the ets and = wps=20 namespaces, we have found several contexts in which the RPH  on the = response is very useful.

1)=20        Error reporting.  RFC 4412 does not give = clear=20 direction on the treatment of RPH with syntax errors (out of range = priority=20 values, duplicate namespaces, etc.)  We have found that including = the RPH=20 in the  4xx responses is usesful in addressing the errors. =
2)        In our = system, we=20 often set the ets  RPH (with default priority)  based on the=20 “ETS-DN”“dialed number” or uri, before = authentication and before knowing the=20 correct priority value.  Including the RPH in the response is a = useful way=20 of conveying the correct priority value back to nodes earlier in the = “call=20 flow”.
3) =      =20  Similarly, if an RP actor receives a SIP INVITE with the ETS-DN, = but no=20 RPH it may, after authenticating the call, include RPH in the responses = in order=20 to inform  nodes earlier in the call flow that this is a priority=20 call.
4)   =    =20  If the RPH is being used to prioritize processing (of both = messages and=20 responses) in the SIP user agent, including the RPH in the response = allows the=20 receiving RP actor to give the response “ETS treatment” = before checking on the=20 “state” of the call.  This is particularly relevant = when the RP actor=20 itself is congested.

Janet

------_=_NextPart_001_01C7BA62.459F18E4-- --===============1370543487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1370543487==-- From sip-bounces@ietf.org Fri Jun 29 13:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju7-0005ox-RN; Fri, 29 Jun 2007 13:05:07 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4Ju6-0005ki-2N for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 13:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju5-0005Sb-7F for sip@ietf.org; Fri, 29 Jun 2007 13:05:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JsR-0004YD-Vo for sip@ietf.org; Fri, 29 Jun 2007 13:03:36 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2007 13:03:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAI7YhEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175486400"; d="scan'208"; a="64023466:sNHT25947242" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5TH3N3Z018538; Fri, 29 Jun 2007 13:03:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5TH3Es0023466; Fri, 29 Jun 2007 17:03:19 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 13:03:14 -0400 Received: from [161.44.174.150] ([161.44.174.150]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 13:03:13 -0400 Message-ID: <46853B4F.10301@cisco.com> Date: Fri, 29 Jun 2007 13:03:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> In-Reply-To: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2007 17:03:13.0753 (UTC) FILETIME=[61288490:01C7BA6F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=636; t=1183136603; x=1184000603; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[Sip]=20WGLC=20for=20draft-ietf-sip-sips-05.txt |Sender:=20 |To:=20Dean=20Willis=20; bh=qnodHZEGcQ7a81ICZ7hwcjezW8kZRDBvmMq+91+rsMU=; b=0eDlVQl2uNkdxeQ8QbqPqZwTdcpi3tWI8Xjy8sbohDEQ5tZkHKayNQiAD1icPOXrmuQTLHwe PKv68a8ggm8dNux2OsmJZ4mMEiqlTAGAqqAxKQF82nvY1axe7j/Oq/Oj; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: IETF SIP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Dean Willis wrote: > > I'm pleased to announce that the authors think that the SIPS draft is > ready for working group last call. This draft has had the privilege of > more review prior to WGLC than most of our other efforts, so perhaps it > won't be too controversial. Right! I'm guessing there will still be a bunch of whining, at least from the usual suspects. I'd just like to get on to talking about something else, including something that is actually useful to constructing secure calls - generally on a best-effort basis since that is all that I expect to be attainable for quite some time. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 13:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4K5m-0003Sw-3J; Fri, 29 Jun 2007 13:17:10 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4K5k-0003RS-4k for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 13:17:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4K3o-00028X-3v for sip@ietf.org; Fri, 29 Jun 2007 13:15:08 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4K1a-0000Ew-5c for sip@ietf.org; Fri, 29 Jun 2007 13:12:50 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5THAiEn009760; Fri, 29 Jun 2007 12:10:44 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5THAha18176; Fri, 29 Jun 2007 12:10:43 -0500 (CDT) Message-ID: <46853D13.7030309@alcatel-lucent.com> Date: Fri, 29 Jun 2007 12:10:43 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] WGLC for draft-ietf-sip-sips-05.txt References: <3D4B049E-23D0-459D-AD58-3D8AF2AB8BE7@softarmor.com> <46853B4F.10301@cisco.com> In-Reply-To: <46853B4F.10301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IETF SIP , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Paul Kyzivat wrote: > I'd just like to get on to talking about something else, including > something that is actually useful to constructing secure calls - > generally on a best-effort basis since that is all that I expect to be > attainable for quite some time. sipsec URI ;-) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Jun 29 14:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LGy-0005an-V4; Fri, 29 Jun 2007 14:32:48 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4LGx-0005aG-LN for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 14:32:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LGx-0005ZS-Ba for sip@ietf.org; Fri, 29 Jun 2007 14:32:47 -0400 Received: from hide.pingtel.com ([65.220.123.2] helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4LGS-0007rA-Fd for sip@ietf.org; Fri, 29 Jun 2007 14:32:47 -0400 Received: from [127.0.0.1] (pi.pingtel.com [10.1.1.12]) by mail.pingtel.com (Postfix) with ESMTP id 2480E6C02C; Fri, 29 Jun 2007 14:31:41 -0400 (EDT) Subject: Re: [Sip] Certificate authentication in SIP From: Scott Lawrence To: IETF SIP List , ietf-pkix@imc.org In-Reply-To: <4685191E.4060903@alcatel-lucent.com> References: <9D18525F6EF33947BDEF23374EF26C7A06CDA1@stntexch11.cis.neustar.com> <9AAEDF491EF7CA48AB587781B8F5D7C6016BA6@srvxchg3.cablelabs.com> <4685191E.4060903@alcatel-lucent.com> Content-Type: text/plain Organization: Pingtel Corp. Date: Fri, 29 Jun 2007 14:32:15 -0400 Message-Id: <1183141935.3646.30.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org On Fri, 2007-06-29 at 09:37 -0500, Vijay K. Gurbani wrote: > Sumanth Channabasappa wrote: > > And if we find that certificates need some work to support this > > initiative (e.g., SIP identifiers as subjects), perhaps we can > > present some of those requirements to other WGs. If we find an > > existing solutions that can be used, good (and we can document them > > as such :) ). > > Scott Lawrence and I have spent some time on this issue, i.e., > SIP identifiers as subjects in X.509 certificates. The latest > version of the draft that includes pkix WG comments from Prague > and the comments of the sip WG ADs and others was posted > last week to the archives, and is available at > http://tools.ietf.org/html/draft-gurbani-sip-domain-certs-05 One qualification - the draft above is limited to certificates as whose subject is a SIP domain - not an individual. The goal is to clarify how such certificates are constructed and constrained, and how they should be used to authenticate that a server is authoritative for a domain. > Comments on this version would be extremely helpful. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:slawrence@pingtel.com sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs Chief Technology Officer - Pingtel Corp. http://www.pingtel.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 sip-bounces@ietf.org Fri Jun 29 17:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Njk-0001mo-J5; Fri, 29 Jun 2007 17:10:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4Nji-0001ma-2h for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 17:10:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Njh-0001mN-82 for sip@ietf.org; Fri, 29 Jun 2007 17:10:37 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Njg-0006u4-Mu for sip@ietf.org; Fri, 29 Jun 2007 17:10:37 -0400 Received: from [10.31.13.108] (stdhcp-108.va.neustar.com [10.31.13.108]) by ns3.neustar.com (Postfix) with ESMTP id DAFDD175EB for ; Fri, 29 Jun 2007 21:10:05 +0000 (GMT) Message-ID: <4685752E.8000608@neustar.biz> Date: Fri, 29 Jun 2007 14:10:06 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> Content-Type: multipart/mixed; boundary="------------010603050206070504010008" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Subject: [Sip] wrt sip-saml feedback X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org This is a multi-part message in MIME format. --------------010603050206070504010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to all who contributed feedback on draft-ietf-sip-saml-02. I've extracted all the editorial comments and entered them into the tracker I've coalesced all the other comments into three broad categories of: substantive, security considerations, and clarifications (see attached notes file). Given the breadth of the various issues embodied therein, I'll endeavor to initiate discussion threads wrt the latter, and from the discussions enter issues into the tracker as appropriate. And I anticipate we'll update the draft as a result of the discussions. thanks again for the feedback, =JeffH --------------010603050206070504010008 Content-Type: text/plain; name="sip-saml-feedback-notes-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sip-saml-feedback-notes-01.txt" sip-saml-feedback-notes-01.txt Fri Jun 29 13:25:10 PDT 2007 edited by: Jeff Hodges ======================================================================== SUBSTANTIVE ======================================================================== -------- Original Message -------- Subject: [Sip] SIP SAML Review by Richard Barnes Date: Wed, 20 Jun 2007 23:44:26 -0400 From: Richard Barnes To: IETF SIP List , Hannes Tschofenig 1. Conveying SAML assertions via a URI in the Identity-Info header contradicts Section 9 of RFC 4474, which says that the resource indicated MUST be of type "application/pkix-cert". ISTM there are at least a couple of ways to fix this: 1.a. Normatively update RFC 4474 to allow the resource to be of either type 1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with one part of each type 1.c. Add a separate header to carry the SAML assertion In the interest of backward-compatibility, I don't think you can get rid of application/pkix-cert altogether. -------- Original Message -------- Subject: [Sip] SIP Saml Review by Marcos Dytz Date: Mon, 18 Jun 2007 10:39:20 +0200 From: Tschofenig, Hannes To: SIP IETF CC: ext Marcos Dytz 1) I believe that it would be good to leave a bit the emphasis on authentication and providing different uses of the protocol (or, at least, specifying that it can be used to convey attributes, query for information, etc). -------- Original Message -------- Subject: [Sip] SIP SAML Draft Review by Sebastian Felis Date: Wed, 27 Jun 2007 12:02:48 +0200 From: Tschofenig, Hannes To: SIP IETF - In my point of view, the draft focuses only on trait-based authorization and tries to deploy trait-based authorization using SAML. It does not try to specify SAML over SIP, which I was expected. Therefore, it is more on an SAML artifact resolution protocol using SIP. The term "artifact resolution protocol" is never mentioned in your draft. And how is the integration of SAML over SIP which carries the assertion in the SIP message, eg. using MIME multiparts. But I guess, this is now concerned by the new issue 10 in http://www.tschofenig.priv.at:8080/saml-sip/issue10. ======================================================================== SECURITY CONSIDERATIONS ======================================================================== -------- Original Message -------- Subject: [Sip] SIP Saml Review by Marcos Dytz Date: Mon, 18 Jun 2007 10:39:20 +0200 From: Tschofenig, Hannes To: SIP IETF CC: ext Marcos Dytz 6) I believe that it is valid that together with signing part of the message, some fields are hashed in order to improve security. -------- Original Message -------- Subject: [Sip] SIP SAML Review by Richard Barnes Date: Wed, 20 Jun 2007 23:44:26 -0400 From: Richard Barnes To: IETF SIP List , Hannes Tschofenig Security / Privacy Concerns: ------------------------------------------------------------------------ 1. It's never made clear what entity is the Subject of the conveyed assertions. This could be a critical distinction, e.g., if one party assumes that it's the UAC being discussed, and the other the user of the UAC. 2. Section 9 needs a discussion the nature of the assurances provided by SAML assertions. In general, in order for it to be verifiable that the SAML assertion was issued by the Authentication Service, there must be proof that the holder of the private key used to create the Identity-Info header. There are several ways to do this: 2.a. The SAML assertion is signed with the appropriate private key 2.b. An unsigned SAML assertion is provided over HTTPS by a server that authenticates with the same certificate 2.c. The Identity-Info is integrity-protected from the point where it is added by the Authentication Service until it reaches the UAS. 3. The list of threats and countermeasures in Section 9 is incomplete. For instance: 3.a. There's no discussion of threats of attacks by elements of the SIP signaling path (e.g., manipulating the URI in the Identity-Info header) 3.b. The anti-replay mechanism should reference the expiry elements built into the assertion (e.g., the NotOnOrAfter attribute) 4. The document isn't clear on whether or not the assertions MUST be signed by the issuer. Section 6.1.5, step 3 seems to imply that the assertion will be signed, but Section 9.3 seems to assume that this isn't necessarily the case. IMHO, it should be that the assertion MUST be signed by the same key used to generate the identity digest. But even if this isn't the case, this point should be clarified. 5. No mention is made of the possible sensitivity of the contents of SAML assertions. It's possible that these assertions could contain sensitive information about the Subject, such as statements about what identities the subject holds. There should be some discussion about what measures should be taken in this case, e.g., the use of HTTPS and authentication of dereferencing clients. Section 6.1.5, Step 3: Section 5.4 of the indicated reference doesn't say anything about how signatures are verified. Instead, this should reference Section 3.2 of the XMLdsig document referenced. Also is this TODO resolved? Section 6.1.5, Step 5: Specify how this verification is done, e.g., by verifying that the signed-identity-digest and the signature on the SAML assertion are both verifiable with the key in the cert in the assertion. Section 6.1.5, Step 7: The relevant field in the X.509 certificate are Subject and Subject Alternative Name (not Issuer and Issuer Alternative Name). The Issuer of the assertion is the Subject of the certificate. -------- Original Message -------- Subject: [Sip] Comments draft-ietf-sip-saml-02 Date: Thu, 21 Jun 2007 16:47:46 +0200 From: Willekens, Marc To: [Page30] Security considerations Is it possible to redirect messages to an own authentication service by manipulating the end-device? How can the called party trust the authentication service assigned by the caller? ======================================================================== CLARIFICATIONS ======================================================================== -------- Original Message -------- Subject: [Sip] SIP Saml Review by Marcos Dytz Date: Mon, 18 Jun 2007 10:39:20 +0200 From: Tschofenig, Hannes To: SIP IETF CC: ext Marcos Dytz 2) The SAML assertion profile sounds weird, although I never completely had a complete grasp of its meaning. I understand that it is connected with the implementation, but it never actually had any particular use to me (or I never gave it much attention). I rather see it as details that developers had to apply in order to have the implementation working and must be added to the specification in order to avoid interoperability issues. 3) I believe it is worth mentioning that one invalid condition locks the whole assertion. 4) I also believe that is worth mentioning that the Identity-Info is connected with CERTS and might go through deployment issues. 5) Is there something missing on 7.1? Sounded incomplete to me. 7) The part of the AS as an authenticator and proxy could be further clarified. -------- Original Message -------- Subject: Re: [Sip] draft-ietf-sip-saml-02 Date: Mon, 18 Jun 2007 01:41:08 +0200 From: Jiri Kuthan To: DRAGE, Keith (Keith) , IETF SIP List CC: sisalem@iptel.org References: <5D1A7985295922448D5550C94DE291800128C14C@DEEXC1U01.de.lucent.com> I'm personally missing scenarios which - use redirection as opposed to proxy mode. IMO, it is beneficial to have the AS operated in 3xx mode for better scalability. - use SAML-by-value, in addition to SAML-by-reference. I personally find the SAML-by-reference quite non-real-time and harder-to-scale too. Perhaps there are arguments why proxy+by/reference is the best thing, but if that's the case I think they should be mentioned in the document. -------- Original Message -------- Subject: RE: [Sip] draft-ietf-sip-saml-02 Date: Mon, 18 Jun 2007 09:44:38 +0200 From: Fries, Steffen To: DRAGE, Keith (Keith) , IETF SIP List - 1 Introduction (page 3) maybe it is worth mentioning in the introduction already that this ID only considers "call by reference" for the assertions and does not provide means for sending the assertion directly. -------- Original Message -------- Subject: [Sip] SIP SAML Review by Andreas Pashalidis Date: Mon, 18 Jun 2007 22:24:19 +0200 From: Hannes Tschofenig To: IETF SIP List CC: Andreas.Pashalidis@netlab.nec.de Here is a review by Andreas Pashalidis: ---------------------- Here are a few small comments: "trait-based" authentication sounds a bit unconventional. Cannot you just talk about "attribute-based" authorization? That would be better aligned with SAML terminology. >From the description in section 5 and figure 1, it is not always clear if you talk about an "authentication assertion" or an "attribute assertion" - Figure 2, step 5: is it possible to have multiple attribute statements in the response? (for example, if possession of multiple attributes is required?) Section 6.1.4.1.4: what does it mean if there is no attribute statement? is it an authentication assertion then? if yes, what would be the authentication context? Section 9.2: it would be nice to have some exaplanation there, without having to refer to a different spec/document. -------- Original Message -------- Subject: [Sip] SIP SAML Review by Richard Barnes Date: Wed, 20 Jun 2007 23:44:26 -0400 From: Richard Barnes To: IETF SIP List , Hannes Tschofenig Figure 2: In the INVITE messages, the AoR in the From: header should be "sip:alice@foo.com" Section 6.1.2, Step 3: The AS is supposed to insert "attributes required by Bob's domain". How is it supposed to know which attributes these are? This is answered by the following paragraph, which should be moved up to here. Section 6.1.2, Step 3: The AS constructs a "HTTP-based SAML URI reference" -- shouldn't this be a reference according to the binding defined in this document, instead of the original (SAMLv2) reference standard? Section 6.1.3.3, third paragraph: This paragraph gives the option of HTTPS or HTTP, but doesn't specify that one of the two MUST be used. Suggested text: "The AS MUST construct either an HTTP or HTTPS URI per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. It is RECOMMENDED that the AS construct an HTTPS URI." Section 6.1.3.3, fourth paragraph: This is not technically correct; the URI should be the absoluteURI portion of the Identity-Info header value. Section 6.1.4: Through out this section, situations with exceptions are presented as "SHOULD ... MAY ...". As I read it, this creates a situation without a mandatory default behavior; I would prefer if these were worded as MUSTs, with MAYs allowed under specified circumstances. Section 6.1.4.1.3: The SHOULDs in this section should be should be MUSTs. Section 6.1.4.1.4, second paragraph: This needs to say that the attribute-value pairs MUST pertain to the subject of the assertion (a concept which needs to be tied to a SIP entity elsewhere in the document). This may be the entity identified in the From header, or another identified entity. Section 7: This binding doesn't really have anything to do with SIP. Could we just exclude SIP from the name? Maybe this could be the IETF standard URI binding of SAML. -------- Original Message -------- Von: ext Mayutan A. [mailto:mayutan.arumaithurai@gmail.com] Gesendet: Mittwoch, 20. Juni 2007 09:45 An: Tschofenig, Hannes Betreff: Re: SIP SAML Comments section 7.1, 3rd para this profile of the SAML URI Binding is congruent with the SAML URI binding ---- does not make sense -------- Original Message -------- Subject: [Sip] Comments draft-ietf-sip-saml-02 Date: Thu, 21 Jun 2007 16:47:46 +0200 From: Willekens, Marc To: [Page 3], Introduction Is this document only about assertion for the authorization or also for the authentication? [Page 12] Domain name for Alice: example.com or foo.com?? (same comment for other figures) Authentication service or Assertion service or both? [Page 13], 6.1. Assertion Fetch profile Is this the only planned profile or will other profiles be defined and added later? Will there also be a push based model? Will it then be "pushed" as part of the SIP message? [Page 13], 6.1.1. URN What's the current consensus for the urn? [Page 17], 6.1.3. ...sender and Authentication service (AS) may be separate or... ??? How will the AS and sender be combined? Should it not be Authentication or Assertion service which can be combined? [Page 22], 6.1.4.1.4. AttributeStatement is indicated. But what about Authentication and Authorization Decision statement? [Page31] This RFC draft talks about assertions. But how can an identity be asserted only by considering a device, e.g. in case a device is stolen or temporary used by someone else? At VON 2000, H. Schulzrinne has already indicated that something as fingerprint has to be added for a device with a changing set of owners. -------- Original Message -------- Subject: [Sip] SIP SAML Draft Review by Sebastian Felis Date: Wed, 27 Jun 2007 12:02:48 +0200 From: Tschofenig, Hannes To: SIP IETF - Another topic is the usage of the term "Authentication Server" which has the acronym AS. Since the term is originating from the trait-based authorization draft, this term should be fine. But from the IMS perspective, the acronym AS is "Application Server". By today, the SIP (p)rotocol is more and more associated with IMS and touches the terms of IMS. Further, the term Authentication Server is not a common term in SAML. So I propose to use another term, which is more SIP/IMS and/or SAML conform, e.g. Identity Provider in case of SAML. === END --------------010603050206070504010008 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --------------010603050206070504010008-- From sip-bounces@ietf.org Fri Jun 29 17:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ODZ-0005Eu-8q; Fri, 29 Jun 2007 17:41:29 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4ODY-0005Ep-6Q for sip-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 17:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ODX-0005Eg-T4 for sip@ietf.org; Fri, 29 Jun 2007 17:41:27 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4OCt-0008QE-JC for sip@ietf.org; Fri, 29 Jun 2007 17:41:27 -0400 Received: from [10.31.13.108] (stdhcp-108.va.neustar.com [10.31.13.108]) by ns1.neustar.com (Postfix) with ESMTP id 4CB0F26E7A for ; Fri, 29 Jun 2007 21:40:47 +0000 (GMT) Message-ID: <46857C60.9010804@neustar.biz> Date: Fri, 29 Jun 2007 14:40:48 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: IETF SIP List References: <4679F41A.4020805@bbn.com> In-Reply-To: <4679F41A.4020805@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Sip] wrt RFC4474 Identity-Info header field referent issue (was: SIP SAML Review by Richard Barnes) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org Richard Barnes wrote: > > 1. Conveying SAML assertions via a URI in the Identity-Info header > contradicts Section 9 of RFC 4474, which says that the resource > indicated MUST be of type "application/pkix-cert". ISTM there are at > least a couple of ways to fix this: > > 1.a. Normatively update RFC 4474 to allow the resource to be of either type > > 1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with > one part of each type > > 1.c. Add a separate header to carry the SAML assertion > > In the interest of backward-compatibility, I don't think you can get rid > of application/pkix-cert altogether. thanks, yes this is definitely an issue. We'd noticied it soon after RFC4474's publication. There was a 3-message thread at the end of Oct-2006 discussing it. Hannes' final message.. Re: [Sip] Re: wrt RFC4474 'absoluteURI' in Identity-Info header field and SIP-SAML implications http://www1.ietf.org/mail-archive/web/sip/current/msg17101.html ..summarizes it well, and proposes essentially Richard's proposed 1.c. solution (note that the ostensible new header would convey a URI rather than a SAML assertion by-value (conveyance of complex objects by-value in SIP header fields being a higher-level (contentious) issue). Also note that this is issue12 in the sip-saml tracker.. http://www.tschofenig.priv.at:8080/saml-sip/issue12 In his message of Tue, 31 Oct 2006 03:54:02 -0400, Hannes was thinking that the equivalent of option 1.c above would be the likely course of action. However, option 1.{a,b} would be possible if draft-ietf-sip-saml-xx were to appropriately normatively update RFC4474 wrt the specific language of the second para of page 15 (in RFC4474). What do folks think we should do here? thanks, =JeffH _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 30 00:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4UA0-0008On-Sj; Sat, 30 Jun 2007 00:02:12 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4U9z-0008Oc-Aj for sip-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 00:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4U9y-0008Nf-WB; Sat, 30 Jun 2007 00:02:11 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4U9s-0002GW-Qw; Sat, 30 Jun 2007 00:02:10 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2946860735; Sat, 30 Jun 2007 12:13:06 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm5b4680f701; Tue, 26 Jun 2007 18:07:57 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmb24679e4ba; Thr, 21 Jun 2007 09:03:41 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 21 Jun 2007 09:03:41 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYU-0007lD-7x; Wed, 20 Jun 2007 20:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1AYQ-0007hQ-EV; Wed, 20 Jun 2007 20:29:42 -0400 Received: from bosco.isi.edu ([128.9.168.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1AYP-0002d6-5C; Wed, 20 Jun 2007 20:29:42 -0400 Received: by bosco.isi.edu (Postfix, from userid 70) id 08838D6BB0; Wed, 20 Jun 2007 17:28:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20070621002824.08838D6BB0@bosco.isi.edu> Date: Wed, 20 Jun 2007 17:28:24 -0700 (PDT) X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: rfc-editor@rfc-editor.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: rfc-editor@rfc-editor.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.0 (++) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4916 on Connected Identity in the Session Initiation Protocol (SIP) X-BeenThere: sip@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4916 Title: Connected Identity in the Session Initiation Protocol (SIP) Author: J. Elwell Status: Standards Track Date: June 2007 Mailbox: john.elwell@siemens.com Pages: 24 Characters: 42924 Updates: RFC3261 See-Also: I-D Tag: draft-ietf-sip-connected-identity-05.txt URL: http://www.rfc-editor.org/rfc/rfc4916.txt This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 30 16:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4j9e-0004M4-65; Sat, 30 Jun 2007 16:02:50 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4j9d-0004Lx-K5 for sip-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 16:02:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4j9d-0004Lp-AZ for sip@ietf.org; Sat, 30 Jun 2007 16:02:49 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4j9Z-0006BT-3J for sip@ietf.org; Sat, 30 Jun 2007 16:02:49 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id D1F6C20042 for ; Sat, 30 Jun 2007 16:02:44 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17027-07 for ; Sat, 30 Jun 2007 16:02:42 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id B5AE92004B for ; Sat, 30 Jun 2007 16:02:42 -0400 (EDT) From: Niall_Gallagher@mitel.com To: sip@ietf.org Message-ID: Date: Sat, 30 Jun 2007 16:02:41 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 06/30/2007 04:02:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Sip] Out of Office -- Niall Gallagher X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I will be out of the office starting 30/06/2007 and will not return until 01/07/2007. I will be on vacation until July 16th and will not be checking email or voicemail. For urgent matters please contact: Prime Contact Backup SIP Interop Mark L'Abbe Tim Kostyniuk SIP Product Management Anshu Prasad Tim Kostyniuk 3600 Product Management Chris Ryerson Tim Kostyniuk MICS Product Management Tom Quan Tim Kostyniuk Mobility Solutions Edmond Helstab Fred McConnell Niall _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Jun 30 21:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4obE-0004cR-Nv; Sat, 30 Jun 2007 21:51:40 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4obD-0004Wz-0m for sip-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 21:51:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4obB-0004Ov-Mw for sip@ietf.org; Sat, 30 Jun 2007 21:51:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4obA-0005Wb-T8 for sip@ietf.org; Sat, 30 Jun 2007 21:51:37 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4oac-0003Gc-6z; Sat, 30 Jun 2007 20:51:03 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) To: IETF SIP Message-Id: From: Dean Willis Date: Sat, 30 Jun 2007 20:50:51 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.7 (/) X-Scan-Signature: b656e85d4d33f5403d96bac6146425d9 Cc: Cullen Jennings , Keith Drage Subject: [Sip] Draft Agenda for SIP at IETF 69 in Chicago X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0147052629==" Errors-To: sip-bounces@ietf.org --===============0147052629== Content-Type: multipart/alternative; boundary=Apple-Mail-4-936504618 --Apple-Mail-4-936504618 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Here's the current draft agenda for SIP at IETF 69. I'm sure it is incomplete. Changes will be posted to: http://www.softarmor.com/mediawiki/index.php/SIP_Agenda_IETF_69 Draft SIP Agenda IETF 69 Session 1, Monday July 23 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0915 SIPS WGLC Francois Audet draft-ietf-sip-sips-05.txt 0945 Outbound Rohan Mahy Cullen Jennings draft-ietf-sip-outbound-09.txt 1015 Location Conveyance WGLC James Polk draft-ietf-sip-location-conveyance-07.txt 1045 Delivering R-URI and Parameters to UA Jonathan Rosenberg draft-rosenberg-sip-ua-loose-route-01.txt 1130 End of Session Session 2, Tuesday July 24 0900-1130 Grand Ballroom Start Time Topic Discussion Lead Reading List 0900 Agenda Bash and Status Chairs This document 0905 SAML Hannes Tschofenig draft-ietf-sip-saml-02.txt 0930 eTags For Notification Aki Niemi draft-ietf-sip-subnot-etags-00.txt 0950 Domain Certs Vijay Gurbani Scott Lawrence draft-gurbani-sip-domain-certs-05.txt 1020 Privacy Guidelines Mayumi Munakata draft-munakata-sip-privacy-guideline-00.txt 1040 Privacy Enhancements Mayumi Munakata draft-munakata-sip-privacy-new-00.txt 1100 Certificate Authentication Sumanth Channabasappa draft-dotson-sip-certificate-auth-03.txt --Apple-Mail-4-936504618 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
Here's the current draft = agenda for SIP at IETF 69. I'm sure it is incomplete. Changes will be = posted to:

Draft SIP Agenda = IETF 69


Session 1, Monday July 23 0900-1130 Grand = Ballroom

<= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
0945
<= TR>
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0915
SIPS WGLC
Francois Audet
Outbound
Rohan Mahy
Cullen Jennings
1015
Location Conveyance = WGLC
James Polk
=
1045
Delivering R-URI and Parameters to = UA
Jonathan Rosenberg
=
1130
End of Session



Session 2, Tuesday July 24 0900-1130 Grand = Ballroom

<= TD valign=3D"middle" style=3D"width: 64.0px; margin: 0.0px 0.5px 0.0px = 0.5px; border-style: solid; border-width: 1.0px 1.0px 1.0px 1.0px; = border-color: #808080 #808080 #808080 #808080; padding: 0.0px 2.0px = 0.0px 2.0px">
0930
Start = Time
Topic
Discussion = Lead
Reading = List
0900
Agenda Bash and Status
Chairs
This = document
0905
SAML
Hannes Tschofenig
eTags For = Notification
Aki Niemi
0950
Domain Certs
Vijay Gurbani
Scott Lawrence
1020
Privacy = Guidelines
Mayumi Munakata
1040
Privacy Enhancements
Mayumi Munakata
1100
Certificate = Authentication
Sumanth Channabasappa
<= /TD>



= --Apple-Mail-4-936504618-- --===============0147052629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0147052629==-- From sip-bounces@ietf.org Sat Jun 30 21:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4odS-0000Xw-DP; Sat, 30 Jun 2007 21:53:58 -0400 Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1I4odR-0000Xf-3S for sip-confirm+ok@megatron.ietf.org; Sat, 30 Jun 2007 21:53:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4odQ-0000XX-Pe for sip@ietf.org; Sat, 30 Jun 2007 21:53:56 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4odQ-0005gX-J9 for sip@ietf.org; Sat, 30 Jun 2007 21:53:56 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4odQ-0003H0-8s for sip@ietf.org; Sat, 30 Jun 2007 20:53:56 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <702E74BC-92DC-4577-A661-A8A53AC49E16@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP From: Dean Willis Date: Sat, 30 Jun 2007 20:53:45 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Sip] Changes on supplemental web site at softarmor.com X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: sip-bounces@ietf.org I'm working on adding to (or possibly replacing) the current web site with a wiki. I'll be using the wiki to do the SIP workup for IETF 69, and if it seems to be ok, we'll be expanding the usage over time. The SIP wiki is hosted at: http://www.softarmor.com/mediawiki/index.php/SIP_Working_Group or https://www.softarmor.com/mediawiki/index.php/SIP_Working_Group if you're willing to trust my bogus certs. -- 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